Add IAuthorizationEvaluator/IAuthorizationHandlerContextFactory

@blowdart @divega
Add a powerful new extensibility point, which enables plugging in different semantics for whether Authorize returns true or not.
Not sure if we have to preserve old ctor parameters as well or not, just to be safe I added an additional ctor for back compat (but I'd prefer just to modify the original if possible)

Hi @HaoK, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by .NET Foundation and real humans are currently evaluating your PR.
TTYL, DNFBOT;

Updated with a factory for replacing the default context as well

Fixes https://github.com/aspnet/Security/issues/879

@divega says :shipit:

thanks for following this up, in addition to the existing default behavior, it is now easy to plugin combining algorithms like 'deny-unless-permit' and 'permit-unless-deny'
the IAuthorizationHandlerContextFactory should help regarding thread safety, however, I'm still not sure 'where to track processed requirements', not every handler evaluates every requirement to 'permit' or 'deny' - XACML even introduces two more states: 'not applicable' and 'indeterminate' (but I think just 'indeterminate' is fine)
while it is definitely possible to track the 'processed' requirements from outside (in the concrete IAuthorizationService implementation), it feels more natural to me to do it within the AuthorizationHandlerContext, that's why I suggested something like
    public class AuthorizationHandlerContext
    {
       public virtual void Fail(IAuthorizationRequirement requirement = null)
       {
           ...

what do you think?

So today we basically only track whether requirements are met, they would be considered indeterminate otherwise.  Fail is meant to kill the entire request irrespective of any requirements state, so I don't really think that jives with having an overload that takes a requirement.  Perhaps the naming of these methods should not be paired (Succeed/FailRequest) might have been a better naming...
I think introducing more detailed states for your requirements is something fairly specific to your IAuthorizationService implementations, and isn't something we are going to bake into the context at this point.  We can certainly considert his for 2.0 when we can make more breaking changes.
What would you expect to be able to do differently based on the various unmet requirement states?  (Which today are all lumped together as failures)

6f15d616a8954420bcb277ed938de1b14f6dbd6f


Hidden.vbs is detected as malware

We are using Trend Micro Deep Security as a server side solution. It is detecting this file as a malware Hacktool.VBS.InviBat.B

Had the same issue but with another AV. As it was being detected via HASH I have just added a comment in that VBS and it was not detected anymore.

same here with trend micro apex one client


"Unable to find the root directory" in multi-module build

In different projects with multiple modules mvnd 1.0-m7 prints in the first line
Unable to find the root directory. Create a .mvn directory in the root directory or add the root="true" attribute on the root project's model to identify it.

But Maven 4.0.0-alpha-8 doesn't complain. In both cases Maven is started from the project root directory. Creating the ".mvn" directory doesn't mute the message printed by mvnd.
$ mvnd -1 -DskipTests clean compile
Unable to find the root directory. Create a .mvn directory in the root directory or add the root="true" attribute on the root project's model to identify it.
[INFO] Processing build on daemon 85f9f7c1
[INFO] Scanning for projects...
[INFO] BuildTimeEventSpy is registered.
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
^C

$ mvn -DskipTests clean compile
[INFO] Scanning for projects...
[INFO] ----------------------------------------------------------------------------------------------------------------
[INFO] Reactor Build Order:
^C

$ mvnd -v
Unable to find the root directory. Create a .mvn directory in the root directory or add the root="true" attribute on the root project's model to identify it.
Apache Maven Daemon (mvnd) 1.0-m7 linux-amd64 native client (b2ef5d81997adbcdb72dc8c5603722538fa641fe)
Terminal: org.jline.terminal.impl.PosixSysTerminal with pty org.jline.terminal.impl.jansi.linux.LinuxNativePty
Apache Maven 4.0.0-alpha-7 (bf699a388cc04b8e4088226ba09a403b68de6b7b)
Maven home: /home/wsl/bin/maven-mvnd-1.0-m7-m40-linux-amd64/mvn
Java version: 21.0.1, vendor: Eclipse Adoptium, runtime: /usr/lib/jvm/temurin-21-jdk-amd64
Default locale: en, platform encoding: UTF-8
OS name: "linux", version: "<IP_ADDRESS>-microsoft-standard-wsl2", arch: "amd64", family: "unix"

$ mvn -v
Apache Maven 4.0.0-alpha-8 (a2cbf4873a99c1aca7e3908086fe53b17865f07a)
Maven home: /home/wsl/bin/apache-maven-4.0.0-alpha-8
Java version: 21.0.1, vendor: Eclipse Adoptium, runtime: /usr/lib/jvm/temurin-21-jdk-amd64
Default locale: en, platform encoding: UTF-8
OS name: "linux", version: "<IP_ADDRESS>-microsoft-standard-wsl2", arch: "amd64", family: "unix"

same behavior in mvnd 1.0-m8

Thanks for the report, @calle2010!
Creating the .mvn directory should solve the issue. I wonder whether there some kind of git push/pull in between that ignores empty directories?

It was changed in alpha-8 - https://issues.apache.org/jira/browse/MNG-7898 - massage is printed in Debug level.
but there is proposition to change level: https://issues.apache.org/jira/browse/MNG-7919


SH+spacebar should trigger page up on detail view

Opposite of how spacebar currently works, which I think is standard for macOS apps.
Using latest stable version of NNW, macOS 10.14.6

I agree. I'm a first-time user of NetNewsWire and RSS, and my natural inclination was that shift-spacebar would page up, similar to web browsers. Maybe I'm a poor reader, but sometimes I race through content, only to page up later to re-read a portion of text. I haven't been able to find a keyboard shortcut for this.
I don't think that shift-spacebar needs to move to the previous article once it reaches the beginning of the current one; just paging up until the beginning of the article would be tremendous.
Thanks! I'm loving NetNewsWire!


How to set the FamilyName?

Due to bug in IE, font FullName MUST begin with FamilyName. For example, if FamilyName is fontello, then FullName should be fontello regular and so on.
How to set it?

This package uses existing data and don't try to change anything. You should have proper ttf souce.
Fontello does necessary workaround https://github.com/fontello/fontello/blob/7.0.0/internal/fontello/font_build/_lib/config.js#L180-L183


Nerd days event page

Description
Add EMEA and APJ event page

Closing since this is a duplicate of #696


Extend Alarmo MQTT to include Notifications (Feature Request)

Hello fellow Home Assistant Alarm creator.  I am the creator and maintainer of the MQTT Alarm Panel application for Home Assistant.  MQTT Alarm Panel is an Android application for wall mounted tablets that works with the MQTT Manual component in HA.  My application already uses MQTT Manual but I have also added the missing night mode (and eventually custom bypass), ability to send a code/command payload, and sensors to display the state of a door sensor for example (open or closed)
Here is my Github repository and the application is also available from Google Play store.
Unfortunately, the MQTT Manual component has been neglected for some time and our PR to update the component was rejected.   So I am reaching out to you because I had some suggestions four how we might extend the MQTT capabilities of your Alarmo integration that would be great for MQTT Alarm panels applications.   In addition to the additional states such as arming night and alarm bypass, I would like to request notifications.
Notifications would be a new topic we subscribe to that sends us status notifications about the alarm state or possibly errors. For example, we might subscribe to topic "home/alarm/notifications" and receive the status of the alarm between states, like going from disarmed to armed_home, might send out a new notification with payload arming_home before we enter the new state.
This tells us that the alarm is arming but also that it is arming to a specific state, it also is more specific than just sending arming state.  Having more specific information tells the UI what is happening so the user can receive proper feedback.  If I am arming away, I show an animation that the user must exist before the alarm is armed.  If I only know the "arming" state, I do not know that it is arming home, bypass, night, or away.
We might also be able to send a notification if the user send an incorrect code to arm or disarm the alarm by sending back a notification message with payload "invalid_code".   The notification topic can be expanded to include whatever additional states or information you want without having to divert from the MQTT Manual component behavior.
The notifications allows me to provide feedback on the tablet to users based on the payload.  They might get a notification for invalid code, or that a sensor is open and the alarm cannot be armed.  Notifications would more closely mirror the functionality in the Alarmo front end.
I would be glad to help along with one of my contributors @derekatkins to add this feature to your integration.
Thanks!

Mister

Hi.  As @thanksmister said, I was working on a PR for the manual_mqtt integration to add these features, but the HA Core team seems uninterested in improving it.  Then we were pointed to Alarmo, which seems to have 95% of the features that @thanksmister and I were were looking to add!  So instead of competing, we would like to help you add that missing 5%!  I am willing to take the work I did for the other component and supply a PR to Alarmo, if you are willing to let us bring those few missing features in?

Hi.  As @thanksmister said, I was working on a PR for the manual_mqtt integration to add these features, but the HA Core team seems uninterested in improving it.  Then we were pointed to Alarmo, which seems to have 95% of the features that @thanksmister and I were were looking to add!  So instead of competing, we would like to help you add that missing 5%!  I am willing to take the work I did for the other component and supply a PR to Alarmo, if you are willing to let us bring those few missing features in?

Hello @thanksmister  and @derekatkins,
I think it could work out brilliantly, combining Alarmo backend with your frontend!
I wouldn't consider this as competing, but joining forces.
In fact your project already came up a couple of times, i think they should work together already.
Alarmo currently features an (optional) MQTT interface to send out state and receive external commands.
There are plans to have this extended:

Allow Alarmo to interface with an external alarm system (so adding a command output topic, and state input topic, so mirrored version of what's currently in place) see https://github.com/nielsfaber/alarmo/issues/35
Add extra topics for diagnostics info (like which sensor triggered, which sensor blocked arming, false pin code entered, etc.)
Currently I am working out the support for multiple area's. Which means multiple alarm_control_panel entities (with an optional 'master')
Allow a JSON mapping from external MQTT interface to the alarmo MQTT interface (so which payload structure + strings are used for which commands, how is pin code sent, etc.)

Now, to get on topic: Alarmo exposes the arm_mode attribute for the alarm_control_panel to distinguish between armed_away, armed_night etc. This attribute is exposed for all states except disarmed.
For me it's a possibility to add a topic for this to have this exposed over MQTT as well (the notification topic as you called it).
Maybe there's an alternative approach that's worth discussing as well:

Alarmo will add a command_out topic, on which the request that was received (either by command_in topic, or by arming from HA) is published (e.g. arm_home) -> this is part of TODO item 1.
The state_out topic, which is now in place, may have payload arming (unchanged)
Combining these items, would give you all the info you need, in a more versatile way (versatile in the sense that HA uses input/output topics for almost all their MQTT components, it seems to interface well with 3rd party systems)

Anyway, lets consider this a kickoff for more discussion.
I'm very much open for contributing PRs, but I would prefer to discuss/align functionality before starting on the implementation part.
Currently I have quite some work locally which will also affects the MQTT implementation, i will commit these changes soon.

Hello @thanksmister  and @derekatkins,
I think it could work out brilliantly, combining Alarmo backend with your frontend!
I wouldn't consider this as competing, but joining forces.
In fact your project already came up a couple of times, i think they should work together already.
Alarmo currently features an (optional) MQTT interface to send out state and receive external commands.
There are plans to have this extended:

Allow Alarmo to interface with an external alarm system (so adding a command output topic, and state input topic, so mirrored version of what's currently in place) see https://github.com/nielsfaber/alarmo/issues/35
Add extra topics for diagnostics info (like which sensor triggered, which sensor blocked arming, false pin code entered, etc.)
Currently I am working out the support for multiple area's. Which means multiple alarm_control_panel entities (with an optional 'master')
Allow a JSON mapping from external MQTT interface to the alarmo MQTT interface (so which payload structure + strings are used for which commands, how is pin code sent, etc.)

Now, to get on topic: Alarmo exposes the arm_mode attribute for the alarm_control_panel to distinguish between armed_away, armed_night etc. This attribute is exposed for all states except disarmed.
For me it's a possibility to add a topic for this to have this exposed over MQTT as well (the notification topic as you called it).
Maybe there's an alternative approach that's worth discussing as well:

Alarmo will add a command_out topic, on which the request that was received (either by command_in topic, or by arming from HA) is published (e.g. arm_home) -> this is part of TODO item 1.
The state_out topic, which is now in place, may have payload arming (unchanged)
Combining these items, would give you all the info you need, in a more versatile way (versatile in the sense that HA uses input/output topics for almost all their MQTT components, it seems to interface well with 3rd party systems)

Anyway, lets consider this a kickoff for more discussion.
I'm very much open for contributing PRs, but I would prefer to discuss/align functionality before starting on the implementation part.
Currently I have quite some work locally which will also affects the MQTT implementation, i will commit these changes soon.

@nielsfaber -

I'm very much open for contributing PRs, but I would prefer to discuss/align functionality before starting on the implementation part.

I promise I wont start coding (or migrating the code I did for manual_mqtt) until we agree on an approach.  Besides, it will take me time to come up to speed with alarmo, so in some cases it may just be easier to convince you to implement it :)   I was just offering to help.
I think the command_out approach works for differentiating between arming_home and arming_away, but we still need a notification feedback for "invalid code".  I guess that could be your TODO # 2?
I don't understand the actual use case for multiple areas?  Could you explain that a bit more?  I DO understand the need for multiple panels (e.g. I have one near my garage entry door and another in the master bedroom), but it's all one house with a coherent alarm, and only a single alarm_control_panel entity in HA.
In terms of the JSON mapping, the main difference I see right now is that I chose to use "action" where you chose "command" in the input json for the command_in MQTT functionality.  But I think that would be easy enough for @thanksmister to change in his app to align with what you've done.

@nielsfaber -

I'm very much open for contributing PRs, but I would prefer to discuss/align functionality before starting on the implementation part.

I promise I wont start coding (or migrating the code I did for manual_mqtt) until we agree on an approach.  Besides, it will take me time to come up to speed with alarmo, so in some cases it may just be easier to convince you to implement it :)   I was just offering to help.
I think the command_out approach works for differentiating between arming_home and arming_away, but we still need a notification feedback for "invalid code".  I guess that could be your TODO # 2?
I don't understand the actual use case for multiple areas?  Could you explain that a bit more?  I DO understand the need for multiple panels (e.g. I have one near my garage entry door and another in the master bedroom), but it's all one house with a coherent alarm, and only a single alarm_control_panel entity in HA.
In terms of the JSON mapping, the main difference I see right now is that I chose to use "action" where you chose "command" in the input json for the command_in MQTT functionality.  But I think that would be easy enough for @thanksmister to change in his app to align with what you've done.

I am up for whatever changes @derekatkins thinks are needed to make.  I just want to be consistent with Manual MQTT because I have many users using this without Alarmo integration and any changes would also need to be easy enough for other users to integrate using automations or whatever equivalent on other home automation platforms.   My objective with MQTT Alarm Panel is to be platform independent by leaning more on MQTT and automations to accomplish everything.

I am up for whatever changes @derekatkins thinks are needed to make.  I just want to be consistent with Manual MQTT because I have many users using this without Alarmo integration and any changes would also need to be easy enough for other users to integrate using automations or whatever equivalent on other home automation platforms.   My objective with MQTT Alarm Panel is to be platform independent by leaning more on MQTT and automations to accomplish everything.

I also have a discord channel for alarm panel discussions if it makes it easier to communicate https://discord.com/invite/euh9J2d.

I also have a discord channel for alarm panel discussions if it makes it easier to communicate https://discord.com/invite/euh9J2d.

I promise I wont start coding (or migrating the code I did for manual_mqtt) until we agree on an approach. Besides, it will take me time to come up to speed with alarmo, so in some cases it may just be easier to convince you to implement it :) I was just offering to help.

I'm fine with both ways. I'm not a hero with python, but the current MQTT implementation is only like 10 lines, so easy to extend.

I think the command_out approach works for differentiating between arming_home and arming_away, but we still need a notification feedback for "invalid code". I guess that could be your TODO # 2?

Yes, exactly. In the Alarmo context, a notification is literally a push/speech message. I think it will be a confusing term to use for this. Also Alarmo defines events, which may be failed_to_arm (due to a wrong code or blocking sensors).
I have a preference to keep such data separated from the arm_mode. The addition of an event output topic (or how we should call it) is IMO a no-brainer. The question is more when it will be added.
If you're OK with combining command_out and state_out data, this would be the ideal match with the planned improvements.

I don't understand the actual use case for multiple areas? Could you explain that a bit more? I DO understand the need for multiple panels (e.g. I have one near my garage entry door and another in the master bedroom), but it's all one house with a coherent alarm, and only a single alarm_control_panel entity in HA.

Alarmo defines entry/exit delays in a centralized way, in the state machine, only customizable per arm_mode.
Users can only define whether a sensor should have a delayed response or immediate response.
I received feedback from users that they would like to have more control. Entering the house through the garage takes several minutes, while opening the frontdoor and disarming is a matter of 30 seconds.
As a solution to this I am adding the option to define a separate area for the house and garage, each with its own timings.
In my own use-case the garage is completely separated from the house, so it can even remain armed while the house is not.
In fact it will result in multiple alarm_control_panel areas (as each can have its own state), but there will be a 'master' entity which will control all simultaneously.
Long story short: the multiple areas feature offers more granularity. Things remain backwards compatible and people don't have to use it.

In terms of the JSON mapping, the main difference I see right now is that I chose to use "action" where you chose "command" in the input json for the command_in MQTT functionality. But I think that would be easy enough for @thanksmister to change in his app to align with what you've done.

Conflicts are inevitable here. Maybe in this case the MQTT Alarm Panel can adapt to Alarmo, but in other cases it is not possible or would require changing embedded code etc. IMO its a must-have to keep this flexible on the HA-side.
Currently users can already customize the payloads for both states and commands.
For the command_in topic there is also some magic in place to parse different JSON structures. Looks like action can be kept as it is.
With adding the command_out topic, the problem arises again, so I would like to try providing a once-and-for-all solution using a JSON mapping option.
Food for thought: would it be desirable to have Alarmo expose the configured arm_modes + delay settings? It seems they are currently hard-coded (correct me if I'm wrong) in MQTT Alarm Panel, but it would be super user-friendly if things can be in sync.

I just want to be consistent with Manual MQTT because I have many users using this without Alarmo integration and any changes would also need to be easy enough for other users to integrate using automations or whatever equivalent on other home automation platforms. My objective with MQTT Alarm Panel is to be platform independent by leaning more on MQTT and automations to accomplish everything.

I understand your point perfectly.
On the other hand, things like diagnostics feedback will improve the user friendliness which they won't have with the manual_mqtt panel (which is intended for basic/generic functionality only).
I'm only offering to help with integrating Alarmo with your project, I see quite some room to add functionality to make the user experience more pleasant.
Since I heard multiple users about the MQTT Alarm Panel, maybe a button can be added to the Alarmo GUI for applying a set of configurations for it, that would make it a plug-and-play experience.
The goal of Alarmo is to have everything set up by GUI, so I don't want to have users bother with topics and payload stuff in YAML. This cannot be said for the manual_mqtt integration.
The only leap people have to make is setting up the custom_component. Luckily this also can be done without coding skills.
Also, someone also made a great video tutorial about Alarmo.

I promise I wont start coding (or migrating the code I did for manual_mqtt) until we agree on an approach. Besides, it will take me time to come up to speed with alarmo, so in some cases it may just be easier to convince you to implement it :) I was just offering to help.

I'm fine with both ways. I'm not a hero with python, but the current MQTT implementation is only like 10 lines, so easy to extend.

I think the command_out approach works for differentiating between arming_home and arming_away, but we still need a notification feedback for "invalid code". I guess that could be your TODO # 2?

Yes, exactly. In the Alarmo context, a notification is literally a push/speech message. I think it will be a confusing term to use for this. Also Alarmo defines events, which may be failed_to_arm (due to a wrong code or blocking sensors).
I have a preference to keep such data separated from the arm_mode. The addition of an event output topic (or how we should call it) is IMO a no-brainer. The question is more when it will be added.
If you're OK with combining command_out and state_out data, this would be the ideal match with the planned improvements.

I don't understand the actual use case for multiple areas? Could you explain that a bit more? I DO understand the need for multiple panels (e.g. I have one near my garage entry door and another in the master bedroom), but it's all one house with a coherent alarm, and only a single alarm_control_panel entity in HA.

Alarmo defines entry/exit delays in a centralized way, in the state machine, only customizable per arm_mode.
Users can only define whether a sensor should have a delayed response or immediate response.
I received feedback from users that they would like to have more control. Entering the house through the garage takes several minutes, while opening the frontdoor and disarming is a matter of 30 seconds.
As a solution to this I am adding the option to define a separate area for the house and garage, each with its own timings.
In my own use-case the garage is completely separated from the house, so it can even remain armed while the house is not.
In fact it will result in multiple alarm_control_panel areas (as each can have its own state), but there will be a 'master' entity which will control all simultaneously.
Long story short: the multiple areas feature offers more granularity. Things remain backwards compatible and people don't have to use it.

In terms of the JSON mapping, the main difference I see right now is that I chose to use "action" where you chose "command" in the input json for the command_in MQTT functionality. But I think that would be easy enough for @thanksmister to change in his app to align with what you've done.

Conflicts are inevitable here. Maybe in this case the MQTT Alarm Panel can adapt to Alarmo, but in other cases it is not possible or would require changing embedded code etc. IMO its a must-have to keep this flexible on the HA-side.
Currently users can already customize the payloads for both states and commands.
For the command_in topic there is also some magic in place to parse different JSON structures. Looks like action can be kept as it is.
With adding the command_out topic, the problem arises again, so I would like to try providing a once-and-for-all solution using a JSON mapping option.
Food for thought: would it be desirable to have Alarmo expose the configured arm_modes + delay settings? It seems they are currently hard-coded (correct me if I'm wrong) in MQTT Alarm Panel, but it would be super user-friendly if things can be in sync.

I just want to be consistent with Manual MQTT because I have many users using this without Alarmo integration and any changes would also need to be easy enough for other users to integrate using automations or whatever equivalent on other home automation platforms. My objective with MQTT Alarm Panel is to be platform independent by leaning more on MQTT and automations to accomplish everything.

I understand your point perfectly.
On the other hand, things like diagnostics feedback will improve the user friendliness which they won't have with the manual_mqtt panel (which is intended for basic/generic functionality only).
I'm only offering to help with integrating Alarmo with your project, I see quite some room to add functionality to make the user experience more pleasant.
Since I heard multiple users about the MQTT Alarm Panel, maybe a button can be added to the Alarmo GUI for applying a set of configurations for it, that would make it a plug-and-play experience.
The goal of Alarmo is to have everything set up by GUI, so I don't want to have users bother with topics and payload stuff in YAML. This cannot be said for the manual_mqtt integration.
The only leap people have to make is setting up the custom_component. Luckily this also can be done without coding skills.
Also, someone also made a great video tutorial about Alarmo.

If you're OK with combining command_out and state_out data, this would be the ideal match with the planned improvements.

I'm not sure what you mean here?  Do you mean combining into one topic?  Or combining into one changeset?

Food for thought: would it be desirable to have Alarmo expose the configured arm_modes + delay settings? It seems they are currently hard-coded (correct me if I'm wrong) in MQTT Alarm Panel, but it would be super user-friendly if things can be in sync.

Amusingly, @thanksmister  and I did this (we called it a "configuration_topic").  HA published a JSON object that contains all the HA configuration, so all the MQTT Alarm Panel needed was the MQTT server and command topic (which defaulted to the default topic), and it could self-configure based on the data received (e.g. other topics, delay times, etc).

If you're OK with combining command_out and state_out data, this would be the ideal match with the planned improvements.

I'm not sure what you mean here?  Do you mean combining into one topic?  Or combining into one changeset?

Food for thought: would it be desirable to have Alarmo expose the configured arm_modes + delay settings? It seems they are currently hard-coded (correct me if I'm wrong) in MQTT Alarm Panel, but it would be super user-friendly if things can be in sync.

Amusingly, @thanksmister  and I did this (we called it a "configuration_topic").  HA published a JSON object that contains all the HA configuration, so all the MQTT Alarm Panel needed was the MQTT server and command topic (which defaulted to the default topic), and it could self-configure based on the data received (e.g. other topics, delay times, etc).

@nielsfaber @derekatkins  it would be good to expose the sensors used (topics and active state), that part I have in the alarm panel already for displaying open/closed states of sensors.
However, for the UI to make use of sensors, we have to know which state is the "on" or active state.  Sensor states are arbitrary as they can be on/off,yes/not,closed,opened,away,home, or anything the user wants.
I don't use delay or pending times from the configuration, instead I rely on state changes or some indicator for state changing.   I already or will support the default modes for MQTT Manual component which I think are pretty universal, so knowing these won't matter.

@nielsfaber @derekatkins  it would be good to expose the sensors used (topics and active state), that part I have in the alarm panel already for displaying open/closed states of sensors.
However, for the UI to make use of sensors, we have to know which state is the "on" or active state.  Sensor states are arbitrary as they can be on/off,yes/not,closed,opened,away,home, or anything the user wants.
I don't use delay or pending times from the configuration, instead I rely on state changes or some indicator for state changing.   I already or will support the default modes for MQTT Manual component which I think are pretty universal, so knowing these won't matter.

@derekatkins

If you're OK with combining command_out and state_out data, this would be the ideal match with the planned improvements.

I'm not sure what you mean here? Do you mean combining into one topic? Or combining into one changeset?

I mean my proposal is to combine the data of the state topic +  command topic for deriving the arm_mode.
It seems to serve more use-cases than the originally proposed notification topic.
For the diagnostics status info a dedicated topic could be added.
@thanksmister

it would be good to expose the sensors used (topics and active state), that part I have in the alarm panel already for displaying open/closed states of sensors.

I'm not sure what you mean here.
How is your MQTT Alarm Panel currently connected to HA for syncing sensor state info?
If it's already working, why would something extra be needed?
Adding this responsibility/functionality to Alarmo seems a bit contradictive to your statement of keeping things compatible to manual_mqtt, or I misunderstand you here.
I'm not sure if exposing sensor states fits with Alarmo.
Currently Alarmo only watches sensor entities when it is armed (and only the sensors which are used in that arm mode).

@derekatkins

If you're OK with combining command_out and state_out data, this would be the ideal match with the planned improvements.

I'm not sure what you mean here? Do you mean combining into one topic? Or combining into one changeset?

I mean my proposal is to combine the data of the state topic +  command topic for deriving the arm_mode.
It seems to serve more use-cases than the originally proposed notification topic.
For the diagnostics status info a dedicated topic could be added.
@thanksmister

it would be good to expose the sensors used (topics and active state), that part I have in the alarm panel already for displaying open/closed states of sensors.

I'm not sure what you mean here.
How is your MQTT Alarm Panel currently connected to HA for syncing sensor state info?
If it's already working, why would something extra be needed?
Adding this responsibility/functionality to Alarmo seems a bit contradictive to your statement of keeping things compatible to manual_mqtt, or I misunderstand you here.
I'm not sure if exposing sensor states fits with Alarmo.
Currently Alarmo only watches sensor entities when it is armed (and only the sensors which are used in that arm mode).

User enters sensor topic and the active "state" into the application.  They need to setup an automation that published the sensor state changes on that topic.   If the state is "active" sensors show green, if state is anything else, sensors will show red. The active state is the state you want for arming the alarm. Here is a screenshot of the active states, user should be able to arm the alarm.

On the automation side, we would want an automation that runs through the sensors looking for open states, and does not arm the alarm, instead sends notification (like alert dialog) back to device saying whatever user wants.  The user currently has to setup these automations.

User enters sensor topic and the active "state" into the application.  They need to setup an automation that published the sensor state changes on that topic.   If the state is "active" sensors show green, if state is anything else, sensors will show red. The active state is the state you want for arming the alarm. Here is a screenshot of the active states, user should be able to arm the alarm.

On the automation side, we would want an automation that runs through the sensors looking for open states, and does not arm the alarm, instead sends notification (like alert dialog) back to device saying whatever user wants.  The user currently has to setup these automations.

Now that the multiple-areas-feature is in place, I could pick this up soon.
To summarize, my proposal:

Alarmo will get a command output topic.
The topic will be user-configurable.
Possible (default) payloads on this topic (depends on user configuration) will be:

DISARM
ARM_AWAY
ARM_HOME
ARM_NIGHT
ARM_CUSTOM_BYPASS

Users can customize the payloads (this is already in place for the command input topic and will be shared), i.e. ARM_AWAY -> LEAVE, ARM_HOME -> STAY etc.
I'm investigating the option for supporting a JSON structure for the payload, such as:

{
  "command": "<command>",
  "code": "<pin or password>",
  "area": "<area_name>"
}

This should remain optional for third party applications that require certain format, so will be user-configurable as well (especially the keys of the JSON struct)

Payload will be published together/simultaneously with the state update (unless the arming fails due to open sensors). Note that alarmo supports switching between arm modes, i.e. transition ARMED_AWAY -> ARMED_HOME may occur.

There will be an option for retaining the payload. It may help with restoring initial state after power loss.

Alarmo will get an event output topic.

The topic will be user-configurable.

This topic will contain info why a command failed (upon sending a command on the input topic):

This may be any of the following reasons:

State transition is not allowed (e.g. requesting ARM_AWAY while in TRIGGERED)
No code was provided while the operation requires a code.
Wrong code or wrong code format provided.
(future use) Too many wrong codes provided, system is temporarily locked.
Code may not be used for the operation (code privilege level insufficient)
One or more sensors are blocking the arming

This topic will contain info why the alarm triggered (similar to "One or more sensors are blocking the arming"). Usually there is only 1 sensor causing the triggering, subsequent sensor changes are ignored and thus not sent.
I'm considering to send data in JSON structure, like:

{
  "event": "<error code / identifier>",
  "message": "<string explaining the error/event>",
  "context": "<array of sensors (entity_IDs? friendly names?) involved in the event if applicable>"
}

I am wondering if this needs to be user-configurable, since it is only diagnostical info from Alarmo.
13. I don't think it makes sense to retain data in the event topic.
I would appreciate your feedback on these items (before I start coding 🙂)
PS: Regarding

it would be good to expose the sensors used (topics and active state), that part I have in the alarm panel already for displaying open/closed states of sensors.

I don't think this fits well in Alarmo, as its really not meant for bridging HA entities to 3rd party apps.
I think it would be better to provide a blueprint/script for it, that users can install in HA directly. There is also a statestreamcomponent that does this (sort of).

Now that the multiple-areas-feature is in place, I could pick this up soon.
To summarize, my proposal:

Alarmo will get a command output topic.
The topic will be user-configurable.
Possible (default) payloads on this topic (depends on user configuration) will be:

DISARM
ARM_AWAY
ARM_HOME
ARM_NIGHT
ARM_CUSTOM_BYPASS

Users can customize the payloads (this is already in place for the command input topic and will be shared), i.e. ARM_AWAY -> LEAVE, ARM_HOME -> STAY etc.
I'm investigating the option for supporting a JSON structure for the payload, such as:

{
  "command": "<command>",
  "code": "<pin or password>",
  "area": "<area_name>"
}

This should remain optional for third party applications that require certain format, so will be user-configurable as well (especially the keys of the JSON struct)

Payload will be published together/simultaneously with the state update (unless the arming fails due to open sensors). Note that alarmo supports switching between arm modes, i.e. transition ARMED_AWAY -> ARMED_HOME may occur.

There will be an option for retaining the payload. It may help with restoring initial state after power loss.

Alarmo will get an event output topic.

The topic will be user-configurable.

This topic will contain info why a command failed (upon sending a command on the input topic):

This may be any of the following reasons:

State transition is not allowed (e.g. requesting ARM_AWAY while in TRIGGERED)
No code was provided while the operation requires a code.
Wrong code or wrong code format provided.
(future use) Too many wrong codes provided, system is temporarily locked.
Code may not be used for the operation (code privilege level insufficient)
One or more sensors are blocking the arming

This topic will contain info why the alarm triggered (similar to "One or more sensors are blocking the arming"). Usually there is only 1 sensor causing the triggering, subsequent sensor changes are ignored and thus not sent.
I'm considering to send data in JSON structure, like:

{
  "event": "<error code / identifier>",
  "message": "<string explaining the error/event>",
  "context": "<array of sensors (entity_IDs? friendly names?) involved in the event if applicable>"
}

I am wondering if this needs to be user-configurable, since it is only diagnostical info from Alarmo.
13. I don't think it makes sense to retain data in the event topic.
I would appreciate your feedback on these items (before I start coding 🙂)
PS: Regarding

it would be good to expose the sensors used (topics and active state), that part I have in the alarm panel already for displaying open/closed states of sensors.

I don't think this fits well in Alarmo, as its really not meant for bridging HA entities to 3rd party apps.
I think it would be better to provide a blueprint/script for it, that users can install in HA directly. There is also a statestreamcomponent that does this (sort of).

I agree, blueprints would be easier for adding sensors to 3rd party alarms, or even if we sent out a sensors config mqtt message, but this can be outside alarmo.
My issues with this part:
  "event": "<error code / identifier>",
  "message": "<string explaining the error/event>",
  "context": "<array of sensors (entity_IDs? friendly names?) involved in the event if applicable>"
}

It's not generic, can't be localized, some 3rd party apps like mine support 9 languages.  If user was able to customize the text, then that would put a lot of setup time on the user.
Maybe you can use codes for different types of issues, but having text breaks localization.  3rd party app can ignore message/context.
You don't want to send out sensor data, but you want to send array of sensor ids or friendly names in the event?  Maybe friendly names are better, not sure entity id's would be much value to the user if they were not the ones creating the sensors (like a spouse or house guest).

Users can customize the payloads (this is already in place for the command input topic and will be shared), i.e. ARM_AWAY -> LEAVE, ARM_HOME -> STAY etc.

Regarding customization, this requires too much work for integration, breaks standardization with other alarm systems, breaks with HA components.
{
  "command": "<command>",
  "code": "<pin or password>",
  "area": "<area_name>"
}

I would recommend to use JSON payload or use additional states such as ARMING_HOME, ARMING_AWAY, but not have both options.   I might suggest adding to the JSON delay time before alarm activates.   Knowing that we are arming to away with a 60 second delay for example.
I don't have any more comments outside of those.

I agree, blueprints would be easier for adding sensors to 3rd party alarms, or even if we sent out a sensors config mqtt message, but this can be outside alarmo.
My issues with this part:
  "event": "<error code / identifier>",
  "message": "<string explaining the error/event>",
  "context": "<array of sensors (entity_IDs? friendly names?) involved in the event if applicable>"
}

It's not generic, can't be localized, some 3rd party apps like mine support 9 languages.  If user was able to customize the text, then that would put a lot of setup time on the user.
Maybe you can use codes for different types of issues, but having text breaks localization.  3rd party app can ignore message/context.
You don't want to send out sensor data, but you want to send array of sensor ids or friendly names in the event?  Maybe friendly names are better, not sure entity id's would be much value to the user if they were not the ones creating the sensors (like a spouse or house guest).

Users can customize the payloads (this is already in place for the command input topic and will be shared), i.e. ARM_AWAY -> LEAVE, ARM_HOME -> STAY etc.

Regarding customization, this requires too much work for integration, breaks standardization with other alarm systems, breaks with HA components.
{
  "command": "<command>",
  "code": "<pin or password>",
  "area": "<area_name>"
}

I would recommend to use JSON payload or use additional states such as ARMING_HOME, ARMING_AWAY, but not have both options.   I might suggest adding to the JSON delay time before alarm activates.   Knowing that we are arming to away with a 60 second delay for example.
I don't have any more comments outside of those.

State transition is not allowed (e.g. requesting ARM_AWAY while in TRIGGERED)
No code was provided while the operation requires a code.
Wrong code or wrong code format provided.
(future use) Too many wrong codes provided, system is temporarily locked.
Code may not be used for the operation (code privilege level insufficient)
One or more sensors are blocking the arming

I would assign an error code to each of these and pass that in the alarm event, then 3rd party apps can display localized messages to the user.

State transition is not allowed (e.g. requesting ARM_AWAY while in TRIGGERED)
No code was provided while the operation requires a code.
Wrong code or wrong code format provided.
(future use) Too many wrong codes provided, system is temporarily locked.
Code may not be used for the operation (code privilege level insufficient)
One or more sensors are blocking the arming

I would assign an error code to each of these and pass that in the alarm event, then 3rd party apps can display localized messages to the user.

@thanksmister

Maybe you can use codes for different types of issues, but having text breaks localization. 3rd party app can ignore message/context.

Agreed that an error code is needed for each condition, this is what I meant with "event": "<error code / identifier>",.
Themessage part could be ignored completely if the error code is interpreted on the other side. Maybe it could be used as a fallback in case the error code is unknown (I guess this is fairly common practise?).
The downside is that you will have to add mapping for these error codes to human-readable texts for display.
This is OK for me, but I understood that you don't want to be tied to Alarmo.
If you have preferences for certain codes/code format, let me know, else I will define them later on.

You don't want to send out sensor data, but you want to send array of sensor ids or friendly names in the event? Maybe friendly names are better, not sure entity id's would be much value to the user if they were not the ones creating the sensors (like a spouse or house guest).

Yes, my proposal is that the context attribute will list the sensors involved in the failed to arm or triggered scenarios.
I don't know enough of your Android Panel to know whether friendly name or entity ID would be preferred.
I assumed you already keep a list of sensor entity IDs with their states from HA (this is what that blueprint MQTT bridge thing should do), so entity ID is a better identifier as it is guaranteed to be unique.
Just so you know: in Alarmo users can assign their own names to sensors which will override the HA friendly_name (i.e. the sensor name could be different to HA entity name).
I'm open to both options, just thought the entity ID would be unambiguous.

Regarding customization, this requires too much work for integration, breaks standardization with other alarm systems, breaks with HA components.

This is needed for allowing users to combine Alarmo with other systems. I heard some people have an MQTT-enabled alarm system and they don't have the freedom to make changes on that end.
So I want to give users the freedom to format a (JSON) payload to a way that is compatible for them.
If your Android panel is able to parse the default HA alarm commands (DISARM, ARM_AWAY, etc.) all should work fine out-of-the-box.
By default the topic will not sent JSON payload and code / area info is not exposed either.

I would recommend to use JSON payload or use additional states such as ARMING_HOME, ARMING_AWAY, but not have both options. I might suggest adding to the JSON delay time before alarm activates. Knowing that we are arming to away with a 60 second delay for example.

As said before, I prefer the addition of the command output topic over the introduction of extra states (Alarmo does not have state ARMING_HOME).
If it is preferred for you, we can also discuss the option of sending JSON payload on the state topic.
The JSON struct could add more info besides the state, such as the arm_mode (armed_away, armed_home, etc.).
In this case reading the command output topic will not be needed anymore for you (I guess).
Delay time (to next state) could also be sent.
BUT: users can (optionally) configure Alarmo to transition from arming -> armed as soon as they close their front door.
In this case the delay time would not be leading, it would be more like a timeout for the arming.

@thanksmister

Maybe you can use codes for different types of issues, but having text breaks localization. 3rd party app can ignore message/context.

Agreed that an error code is needed for each condition, this is what I meant with "event": "<error code / identifier>",.
Themessage part could be ignored completely if the error code is interpreted on the other side. Maybe it could be used as a fallback in case the error code is unknown (I guess this is fairly common practise?).
The downside is that you will have to add mapping for these error codes to human-readable texts for display.
This is OK for me, but I understood that you don't want to be tied to Alarmo.
If you have preferences for certain codes/code format, let me know, else I will define them later on.

You don't want to send out sensor data, but you want to send array of sensor ids or friendly names in the event? Maybe friendly names are better, not sure entity id's would be much value to the user if they were not the ones creating the sensors (like a spouse or house guest).

Yes, my proposal is that the context attribute will list the sensors involved in the failed to arm or triggered scenarios.
I don't know enough of your Android Panel to know whether friendly name or entity ID would be preferred.
I assumed you already keep a list of sensor entity IDs with their states from HA (this is what that blueprint MQTT bridge thing should do), so entity ID is a better identifier as it is guaranteed to be unique.
Just so you know: in Alarmo users can assign their own names to sensors which will override the HA friendly_name (i.e. the sensor name could be different to HA entity name).
I'm open to both options, just thought the entity ID would be unambiguous.

Regarding customization, this requires too much work for integration, breaks standardization with other alarm systems, breaks with HA components.

This is needed for allowing users to combine Alarmo with other systems. I heard some people have an MQTT-enabled alarm system and they don't have the freedom to make changes on that end.
So I want to give users the freedom to format a (JSON) payload to a way that is compatible for them.
If your Android panel is able to parse the default HA alarm commands (DISARM, ARM_AWAY, etc.) all should work fine out-of-the-box.
By default the topic will not sent JSON payload and code / area info is not exposed either.

I would recommend to use JSON payload or use additional states such as ARMING_HOME, ARMING_AWAY, but not have both options. I might suggest adding to the JSON delay time before alarm activates. Knowing that we are arming to away with a 60 second delay for example.

As said before, I prefer the addition of the command output topic over the introduction of extra states (Alarmo does not have state ARMING_HOME).
If it is preferred for you, we can also discuss the option of sending JSON payload on the state topic.
The JSON struct could add more info besides the state, such as the arm_mode (armed_away, armed_home, etc.).
In this case reading the command output topic will not be needed anymore for you (I guess).
Delay time (to next state) could also be sent.
BUT: users can (optionally) configure Alarmo to transition from arming -> armed as soon as they close their front door.
In this case the delay time would not be leading, it would be more like a timeout for the arming.

I would only suggest this for the command:
{
  "command": "<command>",
  "code": "<pin or password>",
  "area": "<area_name>"
  "delay": <int> 0....infinity
}

I think the command as JSON payload is fine, I would not change the state to a JSON payload.  MQTT app users can subscribe to the command out topic and the event topic, using the data they want from these.
I don't have code number suggestions, can be values also like event_error, event_info, or whatever, just something that points back to the exact error codes.   This way MQTT app developers can associate error code/identity with localized messages.
Regarding sending friendly name, if the event is for display purposes, friendly name of component would be preferred as this is the localized name the user has given to the component in most cases. Entity id is of no value that I can see, MQTT app devs have no reference to the entity_id since you are not publishing that as part of a config or anything.   Send both then, if you can't decide, extra information can be ignored.

I would only suggest this for the command:
{
  "command": "<command>",
  "code": "<pin or password>",
  "area": "<area_name>"
  "delay": <int> 0....infinity
}

I think the command as JSON payload is fine, I would not change the state to a JSON payload.  MQTT app users can subscribe to the command out topic and the event topic, using the data they want from these.
I don't have code number suggestions, can be values also like event_error, event_info, or whatever, just something that points back to the exact error codes.   This way MQTT app developers can associate error code/identity with localized messages.
Regarding sending friendly name, if the event is for display purposes, friendly name of component would be preferred as this is the localized name the user has given to the component in most cases. Entity id is of no value that I can see, MQTT app devs have no reference to the entity_id since you are not publishing that as part of a config or anything.   Send both then, if you can't decide, extra information can be ignored.

@thanksmister the transition delay is a property that does not belong to the command, but with the state.
E.g. transitioning from ARMED_AWAY -> TRIGGERED goes via PENDING with a delay entry_time.
The command topic will not be involved in this (only in arming/disarming operation).
It seems like you're asking for having the state topic payload extended with this extra info.
Sending the friendly name of sensor entities I the event context information is OK for me.

@thanksmister the transition delay is a property that does not belong to the command, but with the state.
E.g. transitioning from ARMED_AWAY -> TRIGGERED goes via PENDING with a delay entry_time.
The command topic will not be involved in this (only in arming/disarming operation).
It seems like you're asking for having the state topic payload extended with this extra info.
Sending the friendly name of sensor entities I the event context information is OK for me.

The PENDING with a delay if not much value.  This is one thing we tried to fix with the PR @derekatkins made, we wanted to have a state between ARMED_AWAY and TRIGGERED, DISARMED  and ARM_AWAY. Yeah, this is pending, but it means nothing more than waiting.
We were going to add new states, but you said you were going to use commands instead.  So what is the purpose of the command?  Should it not be fore telling the alarm system what is happening, like we are arming away and we are pending 60 seconds before next command?

The PENDING with a delay if not much value.  This is one thing we tried to fix with the PR @derekatkins made, we wanted to have a state between ARMED_AWAY and TRIGGERED, DISARMED  and ARM_AWAY. Yeah, this is pending, but it means nothing more than waiting.
We were going to add new states, but you said you were going to use commands instead.  So what is the purpose of the command?  Should it not be fore telling the alarm system what is happening, like we are arming away and we are pending 60 seconds before next command?

I was guessing that your wall panel shows a countdown timer when the system is armed and a sensor is tripped, to notify that the user has X time left to disarm the system 'gracefully' until the sirens start.
The question is how you could determine this X if it would not be sent by Alarmo.
I wish I had an Android tablet laying around, I would have tried your project myself 😋 (I sold my soul to Google Home unfortunately).
My idea of the command_out topic, is just to relay an incoming command (arm/disarm) to MQTT, such that all devices would get notified of this. So if someone uses the Lovelace interface to arm the system, your wall panel would be notified of this.
The fact that this info helps to figure out what state comes after ARMING is an additional advantage, but it was not the point.
I sense that we are misunderstanding eachother here, if you think the command_out topic will also be useful for extra sending information, such as delay times.
I'm guessing that the ideal solution for you would be if the state topic would send payloads like:
{
  "state": "ARMING",
  "arm_mode": "ARMED_AWAY",
  "delay": 30,
}

It would give you all the context you need for display purposes. The command_out topic will not be needed for you anymore.
Perhaps @derekatkins could join to share his view on this?

I was guessing that your wall panel shows a countdown timer when the system is armed and a sensor is tripped, to notify that the user has X time left to disarm the system 'gracefully' until the sirens start.
The question is how you could determine this X if it would not be sent by Alarmo.
I wish I had an Android tablet laying around, I would have tried your project myself 😋 (I sold my soul to Google Home unfortunately).
My idea of the command_out topic, is just to relay an incoming command (arm/disarm) to MQTT, such that all devices would get notified of this. So if someone uses the Lovelace interface to arm the system, your wall panel would be notified of this.
The fact that this info helps to figure out what state comes after ARMING is an additional advantage, but it was not the point.
I sense that we are misunderstanding eachother here, if you think the command_out topic will also be useful for extra sending information, such as delay times.
I'm guessing that the ideal solution for you would be if the state topic would send payloads like:
{
  "state": "ARMING",
  "arm_mode": "ARMED_AWAY",
  "delay": 30,
}

It would give you all the context you need for display purposes. The command_out topic will not be needed for you anymore.
Perhaps @derekatkins could join to share his view on this?

The question is how you could determine this X if it would not be sent by Alarmo.

Right now that delay time is "hard coded" in the app (technically it's an app setting, so when you set up the app you set the delay time(s), but IMHO it would be much much better for HA/Alarmo to tell the app the delay time).
Extending the state topic to JSON would solve this, except for the fact that it would break all existing MQTT users, and would be a significant change from, e.g., manual_mqtt.
The other option is to create a new event topic, which we need anyways for feedback like "Invalid code" on disarm.  Instead of command_out (which, technically, the panel doesn't need), or even your JSON state topic, we could put all that information into the event topic:
{
   "event": "TRIGGERED",
   "delay": 30,
}

While the delay times going from DISARMED to ARMED_* are generally constant, I can certainly see use-cases where there are different delay times during TRIGGERED.  For example, I can image a use-case where the delay on my front door is much larger than my garage door, and the delay on my basement door is 0.   So I do think sending the delay time is important (because the app can't know which sensor triggered the alarm).

The question is how you could determine this X if it would not be sent by Alarmo.

Right now that delay time is "hard coded" in the app (technically it's an app setting, so when you set up the app you set the delay time(s), but IMHO it would be much much better for HA/Alarmo to tell the app the delay time).
Extending the state topic to JSON would solve this, except for the fact that it would break all existing MQTT users, and would be a significant change from, e.g., manual_mqtt.
The other option is to create a new event topic, which we need anyways for feedback like "Invalid code" on disarm.  Instead of command_out (which, technically, the panel doesn't need), or even your JSON state topic, we could put all that information into the event topic:
{
   "event": "TRIGGERED",
   "delay": 30,
}

While the delay times going from DISARMED to ARMED_* are generally constant, I can certainly see use-cases where there are different delay times during TRIGGERED.  For example, I can image a use-case where the delay on my front door is much larger than my garage door, and the delay on my basement door is 0.   So I do think sending the delay time is important (because the app can't know which sensor triggered the alarm).

@derekatkins That's a quick reply 👍
I agree 100% on the fact that is best to keep configuration in 1 place, in this case Alarmo, as it manages the alarm state machine.
The delay setting can definitely not be represented by a constant, for Alarmo this depends on which area a sensor is assigned to (garage vs hallway as you said) and a sensor may also be configured to have zero delay (tamper or fire sensor).
So for the Android MQTT Panel, it is preferred to leave the state topic untouched, so only send state info here.
All contextual information can be shared through the event topic.
So far I only considered non-happy-flow events to be sent here (blocking sensors, wrong pincode etc).
But it seems a good idea to extend this and also send payloads during other state transitions, which will contain the contextual info you are looking for.
When arming, I could send as event ARM_AWAY together with the exit delay.
When triggered, the payload would be as you said.
Let's do it like this, I guess we can forget about the command_out topic then (it seems not needed anymore).
Agreed?

@derekatkins That's a quick reply 👍
I agree 100% on the fact that is best to keep configuration in 1 place, in this case Alarmo, as it manages the alarm state machine.
The delay setting can definitely not be represented by a constant, for Alarmo this depends on which area a sensor is assigned to (garage vs hallway as you said) and a sensor may also be configured to have zero delay (tamper or fire sensor).
So for the Android MQTT Panel, it is preferred to leave the state topic untouched, so only send state info here.
All contextual information can be shared through the event topic.
So far I only considered non-happy-flow events to be sent here (blocking sensors, wrong pincode etc).
But it seems a good idea to extend this and also send payloads during other state transitions, which will contain the contextual info you are looking for.
When arming, I could send as event ARM_AWAY together with the exit delay.
When triggered, the payload would be as you said.
Let's do it like this, I guess we can forget about the command_out topic then (it seems not needed anymore).
Agreed?

I should add, I think my suggestion above is missing data.  I think it should be:
{
   "event": "TRIGGERED",
   "delay": 30,
   "sensor": [ .... ]
}

(and maybe additional information?)

I should add, I think my suggestion above is missing data.  I think it should be:
{
   "event": "TRIGGERED",
   "delay": 30,
   "sensor": [ .... ]
}

(and maybe additional information?)

I should add, I think my suggestion above is missing data. I think it should be:
{
   "event": "TRIGGERED",
   "delay": 30,
   "sensor": [ .... ]
}

(and maybe additional information?)

What will be the all the event names?  ARMING_HOME? Would be nice to now the between states from disarmed to armed home, should be arming home with delay time?

I should add, I think my suggestion above is missing data. I think it should be:
{
   "event": "TRIGGERED",
   "delay": 30,
   "sensor": [ .... ]
}

(and maybe additional information?)

What will be the all the event names?  ARMING_HOME? Would be nice to now the between states from disarmed to armed home, should be arming home with delay time?

HA defines the following:
ARM_AWAY
ARM_HOME
ARM_NIGHT
ARM_CUSTOM_BYPASS <--- don't know if you support this one
DISARM

I'm OK with adding the -ing behind all, no preference.
For the initial triggering (so from ARMED_AWAY -> PENDING), I now (internally) use ENTRY (the delay is also called entry delay in Alarmo).
I'm also OK with TRIGGERING but technically this comes later (when the sirens start).
Note that a sensor may also have zero entry delay, in this case it would skip the ENTRY event, it would have event TRIGGER(-ING?).
Note that Alarmo currently will only store+send the sensor which was the root cause of the triggering, not the subsequent tripped sensors.
I don't know if this gives any issues for you?
For the error events we could use the following:
TRANSITION_NOT_ALLOWED: State transition is not allowed (e.g. requesting ARM_AWAY while in TRIGGERED)
CODE_MISSING: No code was provided while the operation requires a code.
CODE_INVALID: Wrong code or wrong code format provided.
CODE_LOCKOUT: (future use) Too many wrong codes provided, system is temporarily locked.
CODE_NOT_ALLOWED: Code may not be used for the operation (code privilege level insufficient)
FAILED_TO_ARM: One or more sensors are blocking the arming

Just some proposal, please shoot 🙂

HA defines the following:
ARM_AWAY
ARM_HOME
ARM_NIGHT
ARM_CUSTOM_BYPASS <--- don't know if you support this one
DISARM

I'm OK with adding the -ing behind all, no preference.
For the initial triggering (so from ARMED_AWAY -> PENDING), I now (internally) use ENTRY (the delay is also called entry delay in Alarmo).
I'm also OK with TRIGGERING but technically this comes later (when the sirens start).
Note that a sensor may also have zero entry delay, in this case it would skip the ENTRY event, it would have event TRIGGER(-ING?).
Note that Alarmo currently will only store+send the sensor which was the root cause of the triggering, not the subsequent tripped sensors.
I don't know if this gives any issues for you?
For the error events we could use the following:
TRANSITION_NOT_ALLOWED: State transition is not allowed (e.g. requesting ARM_AWAY while in TRIGGERED)
CODE_MISSING: No code was provided while the operation requires a code.
CODE_INVALID: Wrong code or wrong code format provided.
CODE_LOCKOUT: (future use) Too many wrong codes provided, system is temporarily locked.
CODE_NOT_ALLOWED: Code may not be used for the operation (code privilege level insufficient)
FAILED_TO_ARM: One or more sensors are blocking the arming

Just some proposal, please shoot 🙂

I added this functionality in the v1.5.2 release of Alarmo.
I wrote down the current implementation in the documentation.
Note that the naming of the events has been changed a bit compared my proposal above.
Couple of things have been altered due to change of insight while working on it:

When a sensor triggers the alarm, the state transition ARMED_<mode>->PENDING->TRIGGERED occurs.
I decided to only fire the TRIGGER event on the first transition.
The delay attribute will tell you when the PENDING->TRIGGERED state transition will follow (there is no need for firing an extra event). delay may be zero, in this case the PENDING state will be skipped.
When arming, the state transition DISARMED->ARMING->ARMED_xx occurs.
I decided to only fire the ARM_<mode> on the first transition (so same as for triggering).
The delay attribute will tell you when the ARMING->ARMED_<mode> state transition will follow (there is no need for firing an extra event). delay may be zero, in this case the ARMING state will be skipped.
CODE_INVALID and CODE_NOT_ALLOWED are merged into INVALID_CODE_PROVIDED. It's rather difficult to make distinction in the code, it doesn't give much extra info anyway.
CODE_LOCKOUT is not implemented yet (since Alarmo does not have any lockout functionality yet). The event list may grow anyway, so perhaps its good to add some catch for unrecognized events.
I don't publish event messages (yet). The event names should be(come) self-explanatory.

I hope the documentation provided a clear picture of what's in place.
There's no problem if things need to be changed or added, just let me know.

I added this functionality in the v1.5.2 release of Alarmo.
I wrote down the current implementation in the documentation.
Note that the naming of the events has been changed a bit compared my proposal above.
Couple of things have been altered due to change of insight while working on it:

When a sensor triggers the alarm, the state transition ARMED_<mode>->PENDING->TRIGGERED occurs.
I decided to only fire the TRIGGER event on the first transition.
The delay attribute will tell you when the PENDING->TRIGGERED state transition will follow (there is no need for firing an extra event). delay may be zero, in this case the PENDING state will be skipped.
When arming, the state transition DISARMED->ARMING->ARMED_xx occurs.
I decided to only fire the ARM_<mode> on the first transition (so same as for triggering).
The delay attribute will tell you when the ARMING->ARMED_<mode> state transition will follow (there is no need for firing an extra event). delay may be zero, in this case the ARMING state will be skipped.
CODE_INVALID and CODE_NOT_ALLOWED are merged into INVALID_CODE_PROVIDED. It's rather difficult to make distinction in the code, it doesn't give much extra info anyway.
CODE_LOCKOUT is not implemented yet (since Alarmo does not have any lockout functionality yet). The event list may grow anyway, so perhaps its good to add some catch for unrecognized events.
I don't publish event messages (yet). The event names should be(come) self-explanatory.

I hope the documentation provided a clear picture of what's in place.
There's no problem if things need to be changed or added, just let me know.

@thanksmister @derekatkins Any comments on this?
It feels a bit weird to me that the discussion suddenly stopped, after spending effort adapting things to your needs.
Or are you busy adapting things on your side 😉 ?

Sorry, I was letting @thanksmister do this thing (they are the App developer; I was working on the manual_mqtt update before I found Alarmo).  I think it sounds good.

I am currently away on vacation, but I think the latest rounds of changes work for me fine.  I will leave any details upt to @derekatkins as he knows best the manual_mqtt component, thanks!

Fair enough, let me know if things are unclear or need to be changed.

@nielsfaber can you help define all the new events.  The documentation doesn't seem to list the new ones.

The documentation is up to date with the current implementation.
What are you missing?

When a sensor triggers the alarm, the state transition ARMED_<mode>->PENDING->TRIGGERED occurs.
I decided to only fire the TRIGGER event on the first transition.
The delay attribute will tell you when the PENDING->TRIGGERED state transition will follow (there is no need for firing an extra event). delay may be zero, in this case the PENDING state will be skipped.
When arming, the state transition DISARMED->ARMING->ARMED_xx occurs.
I decided to only fire the ARM_<mode> on the first transition (so same as for triggering).
The delay attribute will tell you when the ARMING->ARMED_<mode> state transition will follow (there is no need for firing an extra event). delay may be zero, in this case the ARMING state will be skipped.

Hi, I guess I expected to have the events and or commands in the documentation updated with examples of the arming, disarming, pending states?  We had talked about using commands and or/events with delay times when transitioning between states of the alarm.  I am not sure now if we were going to rely on commands or events, I think we were going to update commands?     @derekatkins maybe you can help sort this out, it's a long thread.   I think the commands were to have the arming_home, arming_away, arming_night states as well as the delay times for each?

According to the documentation, commands are sent only for controlling alarmo:

Command topic
The command topic can be used for external control of Alarmo through MQTT.

And for events we have:

The event topic is used for publishing additional status updates of the alarm_control_panel entities.

But from this thread, it seems that you intended to send out "commands" from alarmo:
As said before, I prefer the addition of the command output topic over the introduction of extra states (Alarmo does not have state ARMING_HOME).
I think we need to have either the command or event feature further defined with the extra states in the documentation.  I also think now we have kind of an issue with event and commands having the same functionality.   From the application, I send commands and listen to events.   Events would be where I would expect the ARMING_HOME state to live, along with the delay time.

I'll take a look.  My understanding, @thanksmister , is that there are three topics, the status topic, the command topic and the event topic.

The status topic gives you the current state (DISARMED, ARMING, ARMED_xxx, PENDING, TRIGGERED, etc).
The command topic is input, where you send MQTT commands to control alarmo (JSON with command and code), e.g. { "command": "disarm", "code": "1234" }
The event topic is for extra information during (some) state transitions.  You wont get an event for ALL state transitions.  For example, it will give you the ARMING_HOME event with a delay, or TRIGGERED with a delay.  It won't give you another event goes into ARMED_HOME or TRIGGERED, but that's okay because you'll get a status message when that transition occurs.  The event message is supposed to be JSON, but I'm not 100% sure of the format (I have to go look at the docs, but wont have time to do so for several hours).

The status topic gives you the current state (DISARMED, ARMING, ARMED_xxx, PENDING, TRIGGERED, etc).

I think you mean the state topic? The one used by mqtt manual called state_topic

@thanksmister I think you missed this post: https://github.com/nielsfaber/alarmo/issues/92#issuecomment-769927761
From our communication I understood that it was preferred for you to have the event topic added, which tells you additional info related to state transitions.
It is exactly made as @derekatkins describes:

When the user sets Alarmo for arming, an ARM_AWAY message is fired in the event topic, with the delay until the alarm is armed (so until transition ARMING->ARMED_AWAY) as attribute.
Similarly, if a sensor triggers the alarm, a TRIGGER message is fired, with the delay as attribute (between transition PENDING->TRIGGERED) and the sensor that caused it as attribute.

Please read the docs on the exact payload format, or just install Alarmo and play around with it.
I'm quite sure all is in place that was requested.

@nielsfaber I have noticed what I think is a race condition. When setting the alarm to home mode from HA interface, I sometimes get the event arm_home after the state armed_home.   This makes it difficult to determine which state to follow.  I am not sure having both events and states for alarm states is best approach.   Would maybe have been better if we just modified alarm states with a JSON payload and used events for errors.   Not sure how to address it without just a hack to delay state after events.   Thanks!

@thanksmister The event and state updates are handled asynchronously so there is indeed no guarantee that one comes before the other.
In mqtt there is (AFAIK) also no guarantee that messages arrive at the target in the order in which they are published anyway, so I doubt it can be fixed completely.
In fact not all state transitions comewith  an event, and the other way around, an event can come without a state update.
I think your implementation should take this into account.
I don't want to merge the state and event data into a single topic, as the event data is only providing contextual info so it has a different function.
The state payloads can also not become JSON formatted, as this will (irreversibly) break things for existing users.
Only listening to the state topic will not be a solution either, because as said, not all state updates come with an event (like disarming).
Can you clarify why this behaviour is a problem for you?
I was assuming the arm delay would just help you with showing a countdown timer in the GUI, but if the delay is zero this can be skipped right?

Perhaps if delay=0 we skip sending the event?  Or if delay=0 you ignore the event?  I don't know which is better/easier.

Yeah for my app, I read in the event/state and set the "state" of the alarm.  Originally I think we intended to have new states, rolling them over into events means now we have states and events with alarm mode/state values and then this issue.
I parse out the event and save the state of the alarm to the database, same with states, then I update the UI based on the latest state in the database.   So I would have to hack this to get it to work.
I still think we made a possible bad design choice by adding states or alarm modes to events.  We should have kept states for mqtt manual and then moved all states to events so end user can choose to use events or states, but would not use both.  I am not suggesting you do that, just that this seems to be the issue.

Let me rephrase what @thanksmister is saying:  I think the status topic should be state++.  In other words, I think Alarmo needs to duplicate every message sent to state also to status, where state is just the raw state and status is JSON, so contains all the other information we want/need.
A listener should only subscribe to one topic and be able to get all the data they want/need.  I.e., they should not need to subscribe to both topics, the status topic should be sufficient and get all messages sent.

@thanksmister @derekatkins

A listener should only subscribe to one topic and be able to get all the data they want/need. I.e., they should not need to subscribe to both topics, the events topic should be sufficient and get all messages sent.

I think this is a matter of preference.
If you take a look for example at HA's mqtt light component, you see that it has separate state, brightness, color, effect etc. input/output topics.
Similar things can be seen throughout all HA's mqtt components.
With Alarmo's state/command topics I tried to stick to the same structure, this should be inline with the manual_mqtt component as well.
The event topic is another thing, as it combines different data in a single channel, and it has JSON format.
My idea was to have Alarmo only publish "contextual" data here, giving extra info about a state transition that occured (delay time, involved sensor(s), etc.) or a reason why a arm/disarm command was not allowed.
I thought we both agreed on this in https://github.com/nielsfaber/alarmo/issues/92#issuecomment-769927761.
Apparently there is some misconception here, since you seem to think that the event topic provides a substitute for the state topic.
In its current implementation it's not designed like this, for two reasons:

There are less events defined than there are state transitions (see here for the list of events)
Events are not only fired on state transitions, but also provide feedback when handling commands (wrong code provided, etc.)

I'm a bit hesitant to shuffling things up yet again, given the fact we sent like 20 messages back and forth here before I started implementing what's now in place (which was meant to fulfil your feature request).
It gives me the feeling that later in time you may change insights yet again, and Alarmo needs to keep adapting.
Alarmo is not designed specifically as a back-end for your project, it serves a wider audience.
I would like to keep things generic as much as possible, which means that I want to avoid that the event topic becomes specific for your use-case only, and becomes a replacement for the state topic.
I was under the impression that you wanted to maintain compatibility with the manual_mqtt component, hence the event topic serves as an (optional) layer on top of the state topic.
I still see elegance in this format, so I would prefer to stick to it, rather than sending duplicate info.
Some questions from my side:

Could you share some insight in why it is a problem for you to subscribe to both the state and event topic? I hope you know that mqtt allows subscribing to multiple topics at once using a wildcard (like /alarmo/* to catch /alarmo/state and/alarmo/event)?
In which scenarios do you see difficulties combining the data from both topics to update the GUI? Are we only talking about cases where the alarm is armed without delay time?
If I would be able to tackle the 'race condition' where thestate update  comes before events info, would things be solved for you?
If all looks hopeless here, could you make a proposal how you would like to see the behaviour + payloads of the event topic?

@thanksmister Can you give an update on the status of the integration for Alarmo on your side?
Thanks!

I am working on it and there is already early versions.  Remendado that it already works with Alarmó because it works with MQTT manual.  The test version also sends the code which is compatible with alarmó. The only other integration point is listening for some event messages for errors and the state changes.

@thanksmister OK great to hear there is progress on this!
Please keep me posted if there's any updates.

thanksmister Sorry if I ask you, but I like a lot the colors that your dashbord have,
Can you tell me the name of your dashboard please ?
Thanks a lot


Ez menu icon update

Added three-dot menus in notebooks for both card and list formats

@zarsky-broad is this what you were thinking? This is without vertical centering but size 1.5*(the original). When it's that size, I don't think centering would make much of a difference--thoughts?


Single player instance and reuse in multiple views

Is it possible to create a single instance of the player and dynamically add it in different views? To be specific a frame layout in a recyclerView. And can also have to option to play with different ids.

mm maybe if you initialise and release it each time it could work, but I'm not sure. I suggest trying building a simple demo. Let me know how it goes!

Sure I will revert back in some time

Yeah that makes sense. Glad you figured it out :)

@Sp4Rx  did you find any solution ?

@yasahmed Hey I used it long back, I even forgot in which project I have used it 🥺. Please tell me your problem, or what you have done. May be I can help

@Sp4Rx thank's for your time, i created a single instance of YouTubePlayerView object and i would like to reuse it in multiple views if is it possible

i created a single instance of YouTubePlayerView object and i would like to reuse it in multiple views if is it possible

It's not possible. Unless you manually remove it and add it to each view.

Yes that's what I did I think @PierfrancescoSoffritti.
And @yasahmed  Add a frame layout in the xml. Then on activity get the instance of the frame layout using findViewById on any other method. Now lets assume your Youtube instance name is youtubePlayer and frame layout name is frameLayout.
So to add the view you can do framelayout.addView(youtubePlayer) later remove it from this frame layout before adding to other views else it will throw error.
Tips: Use a handler for view operations. Also use weak reference of context if you are making the youtubePlayer singleton
I just wanted to make you understand the logic. If you find this difficult I will try to create a small demo.

@PierfrancescoSoffritti removing it and add it to a new view stop the player.

@PierfrancescoSoffritti @Sp4Rx this is my question on stackOverflow with an example :
https://stackoverflow.com/questions/68509357/android-youtube-player-video-playing-stopped-when-i-remove-youtubeplayerview-v
the same question on github :
https://github.com/PierfrancescoSoffritti/android-youtube-player/issues/761
Thank's for your time guys

@Sp4Rx Thank you

removing it and add it to a new view pause the player

there's no way around that, i believe

@PierfrancescoSoffritti Thank you very much :)


[Class modifiers] Angular compiler implementation

/cc grouma would this be on your team?

/cc @grouma for real this time :)

@itsjustkevin @leafpetersen - do we actually expect this to affect internal frameworks?
More generally, would it make more sense to track internal framework efforts in the internal bug tracker instead?

@itsjustkevin @leafpetersen - do we actually expect this to affect internal frameworks?

+1.  From a quick glance I don't think there is much work to do on our end. It's possible we need to modify the compiler to improve error handling when the new features are used improperly. We also can take advantage of some of the new features, e.g. sealed types.
cc @leonsenft for additional thoughts.

Agreed. It seems like most of the errors produced by these features would be raised as errors in user authored code before Angular-generated code.

@itsjustkevin @leafpetersen - do we actually expect this to affect internal frameworks?
More generally, would it make more sense to track internal framework efforts in the internal bug tracker instead?

We should still have some way of tracking this here.  @grouma are these already tracked through internal bugs?

For historical context: we added this meta-issue after one feature we added turned out to break the angular compiler when it was used in code that angular consumed (perhaps extension methods?).  The issue is intended to track validating that everything works as intended (or is documented as not working, don't use with angular).  We have historically often opened an internal bug to track any actual work, but since there is no way to link internal bugs into external milestones/projects/etc, we added these issues as part of our release checklist.  I'm fine with any way of tracking this, so long as we have "validate that angular works" on some checklist somewhere.

I added this to the "Dart 3 stable" milestone.
I agree with the sentiments above that I can't think of any way that a user could use Class Modifiers that would crash the Angular compiler, or that would result in UB or something. Any static errors that arise from mis-use of the modifiers should continue to be reported as normal.

Internal tracking id: b/279910423

@grouma, just wondering, can we close this now? ('status: fixed')

Yes this can be closed.

Thanks!


[RESOLVED] Interface eth0(): High error rate (>2 for 5m)

Problem started at 13:21:29 on 2023.08.07
Problem name: Interface eth0(): High error rate (>2 for 5m)
Host: S100-Primario
Severity: Warning
Operational data: errors in: 0, errors out: 0
Original problem ID: 34664
Event details in Zabbix: http://<IP_ADDRESS>/tr_events.php?triggerid=23483&eventid=34664

Problem has been resolved in 12m 0s at 13:33:29 on 2023.08.07
Problem name: Interface eth0(): High error rate (>2 for 5m)
Host: S100-Primario
Severity: Warning
Original problem ID: 34664


Rac 4080 parallel OS tstrap test

This is a new test script that runs Redfish 1.0 OS bootstrap tests in parallel. This dramatically reduces test time from several hours down to 15-20 minutes, making this test suitable for regression suite.
This test allocates available nodes to test cases then runs all of them. 8 nodes are required to run all of the existing test cases. If there are less than 8 nodes, tests will be skipped. Note that Redfish API currently only supports ESXi, CentOS, and RHEL. Tests for other OSs will be added when Redfish API is updated.
Most of the work in this script is done in the header. The test methods are just polling loops to wait for completion of the associated workflow and assert on fail.
@hohene @jimturnquist @larry-dean @stuart-stanley @johren

Found a problem with the script not honoring the group attribute setting. This is because the workflow launch code is outside the scope of the attr decorator. Closing the PR for revision. Will revise and repost later.


doc: GraphQL Generation topic

Add a topic for GraphQL Generation
Contributor checklist

[ ] Bug fixes include regression tests
[ ] Features include unit/acceptance tests
[x] Documentation

This looks great! Would you mind also adding a link to this guide from the bottom of the ash_graphql getting started guide? I've shown some examples of how we do links for compatibility across the various places we show docs.

@zachdaniel Those are great suggestions, and I added them to the PR.


[Feature Request] More Sort-Options for the build list

Hey there!
Here's one for the long term to-do list if it's not on there already:
Make the initial build-list sortable by

Name
Class / Ascendancy
Last edited

Especially "Last edited" would be super handy! ;)
Thank you again for your hard work!

Hmm. This shouldn't be too difficult. I'm currently working on a few other features for the next update, but I'll see if I can get this in too.

It'll be in the next update,
This turned out to be a little trickier than I'd thought, as the Lua code didn't have access to the "last modified" time of the build files. The update will contain a new runtime version to correct this.


[BUG] cannot access menu or start menu

Acknowledgement of preliminary instructions

[X] I have read the preliminary instructions, and I am certain that my problem has not already been addressed.

What problem did you encounter?
Whenever I try to open the menu it only opens the starting Roblox, I cannot access any type of menu on bloxstrap

Never mind.


fix: iOS 15 photo picker thread

The type of this PR is: fix
This PR resolves CX-1794
Description

Moves photo picker configuration to main thread
Fixes some warnings in the photo picker module and navigation button

Not totally clear if this was causing crash but was causing photo picker not to show up on my device on iOS 15 simulator but wasn't crashing.
@pvinis if you could try running on device and seeing if this fixes I would appreciate 🙏
PR Checklist (tick all before merging)

[x] I have included screenshots or videos to illustrate my changes, or I have not changed anything that impacts the UI.
[x] I have tested my changes on iOS and Android.
[x] I have added tests for my changes, or my changes don't require testing, or I have included a link to a separate Jira ticket covering the tests.
[x] I have added a feature flag, or my changes don't require a feature flag. (How do I add one?)
[x] I have documented any follow-up work that this PR will require, or it does not require any.
[x] I have added an app state migration, or my changes do not require one. (What are migrations?)
[x] I have added a changelog entry below or my changes do not require one.

Changelog updates
Changelog updates

Cross-platform user-facing changes

iOS user-facing changes

Fix photo picker presentation on iOS 15 - Brian

Android user-facing changes

Dev changes

This PR contains the following changes:

iOS user-facing changes (Fix photo picker presentation on iOS 15 - Brian)

  Generated by :no_entry_sign: dangerJS against effadadff67c4a89832f13041296a6fdc7f85d70


update to 6.3.0

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Thanks!


fix bug in windows

[x] Do only one thing
[x] Non breaking API changes
[x] Tested

What did this pull request do?

This pr is intent to fix the bug that I made in #5836.
"runtime.Caller" will return path like<EMAIL_ADDRESS>in windows, not "C:\foo\bar".
And "TestSourceDir" redeclared in windows. Even I placed it to "utils_unix_test.go" and "utils_windows_test.go".
User Case Description
See https://github.com/kvii/gormt.git

Hi @kvii
Thank you for the fix, but please don't add the build tag for the windows tests, or we can't cover those cases with GitHub actions.
Thank you.

I made a mistake that I thought the "_unix" suffix was also supported by go.
So I got some "TestFn redeclared in this block" error in windows.
That's the reason I was use build constraint (build tag).
Related go issue: https://github.com/golang/go/issues/51572

@jinzhu I removed build tags in windows tests.

@jinzhu 您方便继续跟进一下这个 windows bug 吗？
"//go:build unix" 确实不能删除。因为如果删除它的话，"utils_unix_test.go" 在 windows 系统下也会被编译。这会导致 window 用户的编译错误！虽然有 "// +build unix" 的文件在 windows 系统下确实不会被编译。但这并不意味着 "_unix.go" 也有同样的作用。具体原因可以参考我之前的评论。在这里再举一个 go 标准库的例子。可以看到 go 源码的 "src/path/filepath/example_unix_test.go" 也使用了 "//go:build"。
https://github.com/golang/go/blob/cf93b25366aa418dea3eea49a7b85447631c2a1d/src/path/filepath/example_unix_test.go#L5
有可能您是让我只删除 "//go:build unix" 那一行。因为项目 go.mod 中的要求的 go 版本为 1.16，而 "//go:build unix" 格式的声明是 go 1.17 的新特性。可能因为您怕新格式和旧版本 go 不兼容。但这应该是您多虑了。因为这种新老版本混合的写法是兼容旧版本的。并且这是新版 go fmt 命令的默认行为。可以参考 [中文博客](https://blog.crazytaxii.com/posts/go_1_17/) 和 [build constaints 设计草案](https://go.googlesource.com/proposal/+/master/design/draft-gobuild.md#compatibility)。
最后很抱歉我使用了中文并且直接 @ 了您。因为我看到已经有 2 个关于这个问题的 issue，说明开发者已经开始陆陆续续地升级到 1.24.1 版本了。我希望这个问题能尽快地被解决。我也为我在 #5836 犯下的错误感到抱歉。

this bug again in the latest version:
gorm.io/driver/mysql v1.5.1
gorm.io/driver/postgres v1.5.2
gorm.io/driver/sqlserver v1.5.1
gorm.io/gorm v1.25.4

@dreamlu Seems like "github.com/casbin/gorm-adapter/v3" it not an official package. Gorm only filters source path contains   "gorm.io".

@dreamlu Seems like "github.com/casbin/gorm-adapter/v3" it not an official package. Gorm only filters source path contains "gorm.io".
gormSourceDir = "/Users/name/go/pkg/mod/gorm.io/" at runtime.
https://github.com/go-gorm/gorm/blob/e57e5d8884d801caa4ce0307bcd081f7e889e514/utils/utils.go#L36-L41

in that picture, the right is printed by
github.com/casbin/gorm-adapter/v3
this project use old gorm version and is right

in that picture, the not right print is printed by
gorm.io/driver/mysql v1.5.1
gorm.io/driver/postgres v1.5.2
gorm.io/driver/sqlserver v1.5.1
gorm.io/gorm v1.25.4

my system：
linux
goland 2023.2.1

@dreamlu What's your expect behavior?
reproduce repo

same problem:
https://github.com/go-gorm/gorm/issues/5870

Is there anyone can solve the problem？

You should create a new issue and provide a minimal reproduction project if you want to solve this "problem".
Although in my personal opinion it just because your path contains Chinese. @dreamlu


[Question]:

请提出你的问题
How to encode a "single word" as a single token after tokenizer's encoding? And even more, I need to inject some words linked by some symbol as a "single token"...
If not, the following issue would raise
    # Convert the initializer_token, placeholder_token to ids
    token_ids = tokenizer.encode(args.initializer_token,
                                 add_special_tokens=False)["input_ids"]
    # Check if initializer_token is a single token or a sequence of tokens
    if len(token_ids) > 1:
        raise ValueError("The initializer token must be a single token.")

ref: token_ids = tokenizer.encode(args.initializer_token,
The init token might be split into multiple tokens by mistake, e.g. [bookcase] -> [book, case] -> [2828, 2068], which we suppose to be a single token [bookcase] -> [ $some_id ].
I've tried:

"bookcase" -> [book, case] -> [2828, 2068]
"book-case" -> [book, -, case] -> [1116, 268, 2068]
"[bookcase]" -> ['[', book, case, ']'] -> [314, 2828, 2068, 316]

你好，可以尝试增加special tokens来解决该问题，例如
tokenizer = GPTTokenizer.from_pretrained('gpt2-en')
tokenizer.add_tokens(['godlockin'], True)

it works, and also support Chinese terms, cheers


Changing Spatial Awareness Display Option at runtime is unclear

This tip is unclear:

If you want to see the Spatial Awareness Mesh when testing the Tap To Place functionality on your HoloLens, you can temporarily set the Spatial Mesh Observer's Display Option to Visible. For a reminder on how to change the Display Option, you can refer to the Changing the Spatial Awareness Display Option instructions.

The linked page shows you how to create a new custom profile and manually change the spatial awareness display option, but doesn't include instructions about procedurally changing the display option at runtime. I'm not sure how to handle that, in following the tutorial I might have expected to drag something into the TapToPlace component's OnPlacingStarted and OnPlacingStopped events.

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

ID: a441bd4f-7fb9-780a-696c-6b07fee8c179
Version Independent ID: 76453e28-721e-92ee-122c-f1f5ca571377
Content: Creating dynamic content using Solvers - Mixed Reality
Content Source: mixed-reality-docs/mr-dev-docs/develop/unity/tutorials/mr-learning-base-05.md
Product: mixed-reality
Technology: mr-dev
GitHub Login: @jessemcculloch
Microsoft Alias: jemccull

@RogPodge Can you assist?

The question has been answered here, @hferrone please close the issue.

@justinpando You can also check out this video (43:53)
https://channel9.msdn.com/Shows/Mixed-Reality/MRTKs-UX-Building-Blocks


Added try/catch block around API calls and log error to stderror

Is it a good thing to console.log() the errors?
Since those error messages can be easily accessed, are we sure that they will not show any sensitive information?

@gerep From my tests of seeing some of the failures I triggered I did not see any sensitive data. Are you suggesting just logging the message?

Yes, I think it would be better/safer.


#r relative reference cannot find file after reset F# interactive in MonoDevelop

From @colinfang on September 18, 2014 14:5
After I hit reset or #q, relative references #r "../..." added to the script no longer works.
Copied from original issue: fsharp/fsharpbinding#738

From @colinfang on September 18, 2014 15:53
The problem occurs to #I as well

Closing, moved to bugzilla: https://bugzilla.xamarin.com/show_bug.cgi?id=33090


Seems doesn't support BO/CO

Amazing work btw. I was wondering if it could support BO/CO Orders. Anyway amazing it is

Can you help me developing it in .NET language?

It should support BO/CO order..
I havent tested it.. I would suggest you to use kiteconnect as I am no longer developing this further.