Colour contrast accessibility in Bootstrap Blue & Grey theme

The $brightcolor value #0098C3 is flagged up by accessibility checker (e.g. WAVE) as not having enough contrast with white.  Suggested value is #007395.

@takadachi It looks like this was fixed sometime ago (https://github.com/thexerteproject/xerteonlinetoolkits/commit/d51fb0d15d2fed831448f9f778e4b322339ec0c4 3.12?)


Alarmo stops sending notification after longer Arm Away status

Alarmo Version
v1.9.10
HA Version
2023.7
Bug description
I have setup a separate zone of Alarmo in my garage with only one PIR sensor. Usually that zone is always armed since i bearly go to the garage. Even if i go it is only for short period of time. In that short periods I dont bother to disarm the alarm and it sends me a notifiocation that there is trigger in the Garage. But after one day of staying in armed state I stop receiving any notifications. If i disarm and arm the alarm again it continues to work.
Steps to reproduce

Arm a zone
Trigger PIR in that zone, wait for the zone to enter Armed state again after triggered state.
(i think that is optional i think the main problem is longer period of time that is causing the issue)
Wait 24h or more without triggering again.
Try to trigger the alarm it wont send any notifications.

Relevant log output
No response

@nielsfaber The PIR sensor is activating i can see the events in the history. But the alarm state stays Away all the time. Please note that i have two Areas. Main House and Garage.  Here is a graph showing exactly what happens.

I dont know how Alarmo is coded, maybe it uses event, maybe cron jobs. Sorry for guessing out, but my guess is that maybe something at midnight is causing this behavior to detach events or crons...
And also shouldnt the master state be returned to Away when the garage area also returns to away?

Thanks for sharing this info.
From the picture you sent I see two periods during which the sensor triggers but the alarm does not, all the way at the beginning and from the afternoon on August 1 onwards.

Are you certain this sensor is assigned to the garage area?
Am I correctly assuming you configured the alarm to return to armed state after the trigger time has expired?

And also shouldnt the master state be returned to Away when the garage area also returns to away?

This depends on the states of the other areas.
The behaviour is described here.
I will setup some test which enables a dummy sensor for a short moment every ~12 hours, and link it to an area.
This should mimic the same pattern as you have, so in a couple of days I should be able to have reproduced the issue.
I will share the results when I have them.

I have the same problem, although it triggered the alarm two times as expected until day 4 in away mode. On day 6, three motion sensors in a sensor group fired, but Alarmo stayed in armed mode. Manually disarming Alarmo and arming it again, solves the issue temporarily.

@nielsfaber @sec4563 i am almost positive that this happens because of notifications. I disabled notifications in the actions tab and it looks like it is triggering fine now though only 24 hours passed. I will wait another 24-48 and post the results.

No, it's not the notifications, it happened again even with notifications turned off. It may be because there is high amount of movement.

In my own test which activates a sensor every day around 18:00 I have not encountered any failure of triggering the alarm (it runs now for 5 days).

The issue seems not very easy to reproduce, at least not as easy as described in the initial bug report.
I cannot think of any relation with notifications as they are handled separately in Alarmo and always occur as consequence of the state change of the alarm entity, so they shouldn't block this.
In my test I have also notification being sent and this has not failed either.
There could be a relation with the amount of sensor activity and of course also with other things happening in HA.
However this makes finding the root cause a challenge, there's also a chance the issue resides in HA itself (Alarmo depends on HA functions, for example for the registration to sensor state changes).
I appreciate the effort you spend into this, let's keep gathering statistics and hopefully pinpoint to the issue.
Note that you could enable the debug logging for Alarmo, for example by adding this to the configuration.yaml (requires restarting HA):
logger:
  default: warning
  logs:
    custom_components.alarmo: debug

This will add quite some spam to your HA logs (be warned), but it should also print a line every time a sensor changes:

2023-08-07 17:28:00.260 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.motion_entrance changed: old_state=closed, new_state=open

It would be very helpful to have the loggings around the time whenever the alarm fails to trigger.

@nielsfaber it happened again. The Debug was printing states of the sensor and alarm in the log, but after the problem happened the log is empty i cannot see the PIRs being active or any problem/exception. Though in history i can see the PIRs continue to be active.

2023-08-08 13:04:33.156 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.garage was updated from armed_away to pending 2023-08-08 13:04:33.156 INFO (MainThread) [custom_components.alarmo.alarm_control_panel] Alarm will be triggered after 20 seconds. 2023-08-08 13:04:33.156 DEBUG (MainThread) [custom_components.alarmo.automations] state of alarm_control_panel.garage is updated from armed_away to pending 2023-08-08 13:04:33.156 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.master was updated from triggered to pending 2023-08-08 13:04:33.156 DEBUG (MainThread) [custom_components.alarmo.automations] state of alarm_control_panel.master is updated from triggered to pending 2023-08-08 13:04:36.479 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=open, new_state=closed 2023-08-08 13:04:36.786 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=closed, new_state=open 2023-08-08 13:04:40.164 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=open, new_state=closed 2023-08-08 13:04:53.157 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] async_entry_timer_finished 2023-08-08 13:04:53.157 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.garage was updated from pending to triggered 2023-08-08 13:04:53.158 INFO (MainThread) [custom_components.alarmo.alarm_control_panel] Alarm is triggered! 2023-08-08 13:04:53.158 DEBUG (MainThread) [custom_components.alarmo.automations] state of alarm_control_panel.garage is updated from pending to triggered 2023-08-08 13:04:53.158 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.master was updated from pending to triggered 2023-08-08 13:04:53.158 DEBUG (MainThread) [custom_components.alarmo.automations] state of alarm_control_panel.master is updated from pending to triggered 2023-08-08 13:07:10.350 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=closed, new_state=open 2023-08-08 13:07:13.892 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=open, new_state=closed 2023-08-08 13:08:00.306 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=closed, new_state=open 2023-08-08 13:08:03.719 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=open, new_state=closed 2023-08-08 13:08:04.836 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=closed, new_state=open 2023-08-08 13:08:11.591 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=open, new_state=closed 2023-08-08 13:09:53.158 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] async_trigger_timer_finished 2023-08-08 13:09:53.158 INFO (MainThread) [custom_components.alarmo.alarm_control_panel] Alarm 'Garage' is armed (armed_away). 2023-08-08 13:09:53.158 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.garage was updated from triggered to armed_away 2023-08-08 13:09:53.160 DEBUG (MainThread) [custom_components.alarmo.automations] state of alarm_control_panel.garage is updated from triggered to armed_away 2023-08-08 13:12:51.840 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=closed, new_state=open 2023-08-08 13:12:51.840 INFO (MainThread) [custom_components.alarmo.sensors] Alarm is triggered due to sensor: binary_sensor.garage_pir_1 2023-08-08 13:12:51.840 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.garage was updated from armed_away to pending 2023-08-08 13:12:51.840 INFO (MainThread) [custom_components.alarmo.alarm_control_panel] Alarm will be triggered after 20 seconds. 2023-08-08 13:12:51.840 DEBUG (MainThread) [custom_components.alarmo.automations] state of alarm_control_panel.garage is updated from armed_away to pending 2023-08-08 13:12:51.840 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.master was updated from triggered to pending 2023-08-08 13:12:51.840 DEBUG (MainThread) [custom_components.alarmo.automations] state of alarm_control_panel.master is updated from triggered to pending 2023-08-08 13:12:55.352 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=open, new_state=closed 2023-08-08 13:13:05.742 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=closed, new_state=open 2023-08-08 13:13:08.893 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=open, new_state=closed 2023-08-08 13:13:11.841 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] async_entry_timer_finished 2023-08-08 13:13:11.841 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.garage was updated from pending to triggered 2023-08-08 13:13:11.841 INFO (MainThread) [custom_components.alarmo.alarm_control_panel] Alarm is triggered! 2023-08-08 13:13:11.841 DEBUG (MainThread) [custom_components.alarmo.automations] state of alarm_control_panel.garage is updated from pending to triggered 2023-08-08 13:13:11.841 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.master was updated from pending to triggered 2023-08-08 13:13:11.841 DEBUG (MainThread) [custom_components.alarmo.automations] state of alarm_control_panel.master is updated from pending to triggered 2023-08-08 13:13:19.711 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=closed, new_state=open 2023-08-08 13:13:25.106 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=open, new_state=closed 2023-08-08 13:13:29.739 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=closed, new_state=open 2023-08-08 13:13:32.891 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=open, new_state=closed 2023-08-08 13:13:37.827 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=closed, new_state=open 2023-08-08 13:13:43.824 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=open, new_state=closed 2023-08-08 13:17:52.213 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=closed, new_state=open 2023-08-08 13:17:58.891 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=open, new_state=closed 2023-08-08 13:18:09.276 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=closed, new_state=open 2023-08-08 13:18:11.841 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] async_trigger_timer_finished 2023-08-08 13:18:11.841 INFO (MainThread) [custom_components.alarmo.alarm_control_panel] Alarm 'Garage' is armed (armed_away). 2023-08-08 13:18:11.842 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.garage was updated from triggered to armed_away 2023-08-08 13:18:11.843 DEBUG (MainThread) [custom_components.alarmo.automations] state of alarm_control_panel.garage is updated from triggered to armed_away 2023-08-08 14:23:28.624 WARNING (MainThread) [homeassistant.components.androidtv_remote] Disconnected from Android TV at <IP_ADDRESS>

@nielsfaber it happened again. The Debug was printing states of the sensor and alarm in the log, but after the problem happened the log is empty i cannot see the PIRs being active or any problem/exception. Though in history i can see the PIRs continue to be active.

2023-08-08 13:04:33.156 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.garage was updated from armed_away to pending 2023-08-08 13:04:33.156 INFO (MainThread) [custom_components.alarmo.alarm_control_panel] Alarm will be triggered after 20 seconds. 2023-08-08 13:04:33.156 DEBUG (MainThread) [custom_components.alarmo.automations] state of alarm_control_panel.garage is updated from armed_away to pending 2023-08-08 13:04:33.156 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.master was updated from triggered to pending 2023-08-08 13:04:33.156 DEBUG (MainThread) [custom_components.alarmo.automations] state of alarm_control_panel.master is updated from triggered to pending 2023-08-08 13:04:36.479 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=open, new_state=closed 2023-08-08 13:04:36.786 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=closed, new_state=open 2023-08-08 13:04:40.164 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=open, new_state=closed 2023-08-08 13:04:53.157 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] async_entry_timer_finished 2023-08-08 13:04:53.157 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.garage was updated from pending to triggered 2023-08-08 13:04:53.158 INFO (MainThread) [custom_components.alarmo.alarm_control_panel] Alarm is triggered! 2023-08-08 13:04:53.158 DEBUG (MainThread) [custom_components.alarmo.automations] state of alarm_control_panel.garage is updated from pending to triggered 2023-08-08 13:04:53.158 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.master was updated from pending to triggered 2023-08-08 13:04:53.158 DEBUG (MainThread) [custom_components.alarmo.automations] state of alarm_control_panel.master is updated from pending to triggered 2023-08-08 13:07:10.350 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=closed, new_state=open 2023-08-08 13:07:13.892 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=open, new_state=closed 2023-08-08 13:08:00.306 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=closed, new_state=open 2023-08-08 13:08:03.719 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=open, new_state=closed 2023-08-08 13:08:04.836 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=closed, new_state=open 2023-08-08 13:08:11.591 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=open, new_state=closed 2023-08-08 13:09:53.158 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] async_trigger_timer_finished 2023-08-08 13:09:53.158 INFO (MainThread) [custom_components.alarmo.alarm_control_panel] Alarm 'Garage' is armed (armed_away). 2023-08-08 13:09:53.158 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.garage was updated from triggered to armed_away 2023-08-08 13:09:53.160 DEBUG (MainThread) [custom_components.alarmo.automations] state of alarm_control_panel.garage is updated from triggered to armed_away 2023-08-08 13:12:51.840 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=closed, new_state=open 2023-08-08 13:12:51.840 INFO (MainThread) [custom_components.alarmo.sensors] Alarm is triggered due to sensor: binary_sensor.garage_pir_1 2023-08-08 13:12:51.840 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.garage was updated from armed_away to pending 2023-08-08 13:12:51.840 INFO (MainThread) [custom_components.alarmo.alarm_control_panel] Alarm will be triggered after 20 seconds. 2023-08-08 13:12:51.840 DEBUG (MainThread) [custom_components.alarmo.automations] state of alarm_control_panel.garage is updated from armed_away to pending 2023-08-08 13:12:51.840 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.master was updated from triggered to pending 2023-08-08 13:12:51.840 DEBUG (MainThread) [custom_components.alarmo.automations] state of alarm_control_panel.master is updated from triggered to pending 2023-08-08 13:12:55.352 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=open, new_state=closed 2023-08-08 13:13:05.742 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=closed, new_state=open 2023-08-08 13:13:08.893 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=open, new_state=closed 2023-08-08 13:13:11.841 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] async_entry_timer_finished 2023-08-08 13:13:11.841 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.garage was updated from pending to triggered 2023-08-08 13:13:11.841 INFO (MainThread) [custom_components.alarmo.alarm_control_panel] Alarm is triggered! 2023-08-08 13:13:11.841 DEBUG (MainThread) [custom_components.alarmo.automations] state of alarm_control_panel.garage is updated from pending to triggered 2023-08-08 13:13:11.841 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.master was updated from pending to triggered 2023-08-08 13:13:11.841 DEBUG (MainThread) [custom_components.alarmo.automations] state of alarm_control_panel.master is updated from pending to triggered 2023-08-08 13:13:19.711 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=closed, new_state=open 2023-08-08 13:13:25.106 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=open, new_state=closed 2023-08-08 13:13:29.739 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=closed, new_state=open 2023-08-08 13:13:32.891 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=open, new_state=closed 2023-08-08 13:13:37.827 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=closed, new_state=open 2023-08-08 13:13:43.824 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=open, new_state=closed 2023-08-08 13:17:52.213 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=closed, new_state=open 2023-08-08 13:17:58.891 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=open, new_state=closed 2023-08-08 13:18:09.276 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.garage_pir_1 changed: old_state=closed, new_state=open 2023-08-08 13:18:11.841 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] async_trigger_timer_finished 2023-08-08 13:18:11.841 INFO (MainThread) [custom_components.alarmo.alarm_control_panel] Alarm 'Garage' is armed (armed_away). 2023-08-08 13:18:11.842 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.garage was updated from triggered to armed_away 2023-08-08 13:18:11.843 DEBUG (MainThread) [custom_components.alarmo.automations] state of alarm_control_panel.garage is updated from triggered to armed_away 2023-08-08 14:23:28.624 WARNING (MainThread) [homeassistant.components.androidtv_remote] Disconnected from Android TV at <IP_ADDRESS>

A small update from my side.
I have left the automated daily sensor triggering running for another week.
From the history I can see that the alarm is triggered every time.

I think we can conclude that the issue is not related to a 'longer arm away status' as the initial bug report states.
The issue seems related to a specific usage pattern, possibly the large amount of sensor triggering.
Which also means it will be difficult for me to reproduce and tackle this issue on my own.
The logging you shared suggests that either:

Alarmo was not actively watching state changes of the sensor anymore
HA failed to forward the triggering of the sensor to Alarmo
Alarmo (falsely) concluded the sensor was in the safe state and ignored the trigger

In order to pinpoint which scenario occurred some extra logging info is required.
I made some modifications to the code which add this info (printed in the debug log).
If you could download the attached file and overwrite your local sensors.py file in the custom_components/alarmo directory with this version that would be very helpful.
Note I attached the file as .txt since github doesn't allow direct uploading of .py files, either the extension should be renamed or the contents of the current sensors.py file should be replaced with the content of the changed file.
After changing it, HA needs to be restarted to load the new file.
If something goes wrong or you want to stop debugging, the original file can always be found here https://github.com/nielsfaber/alarmo/blob/v1.9.10/custom_components/alarmo/sensors.py.
Thanks in advance for your willingness to help with this issue.
sensors.txt

I have got the same behavior but it's not to long Arm Away rather to when it goes from Armed Away to Triggered and then when it comes back to Armed Away no trigger is detected any more. I "hot fix" it at my system in the way that when it comes from Triggered to Armed Away state that I disarm it and arm it again in Armed Away state and no problems then.
For me it seems that when it comes from Triggered back to Armed Away that it don't detect any states or it cannot got to Triggering state again.  It is not connected with the time spent in initial Armed Away state.

@deadly667 Are you able to reproduce this in your setup, or is this not always the case?
As I explained in my previous post, I have ran a test for almost 2 weeks where the alarm gets triggered by a sensor and then returns to the armed state. I haven't seen any of the behaviour you describe.
If the scenario is easy to test for you, it would be great if you can get a debug logging of the event. I shared a modified file with extra logging, this should give more insight in the situation.
The reliability of alarmo is most important to me, so I would like to tackle this issue as soon as possible.

Hello, I have the same issue. It seems it doesn't related to the type of arming (home, night, away).
I have setup, similar to the topic starter: motion sensor and magnet door sensor in the garage, which I wish to keep armed all the time. Only door sensor trigger alarms more or less reliable, while motion sensor doesn't.
I installed sensor.txt from above. Attaching here some log from this morning.
2023-09-11 08:46:51.835 DEBUG (MainThread) [custom_components.alarmo.automations] state of alarm_control_panel.alarmo is updated from triggered to armed_home
2023-09-11 09:52:14.984 DEBUG (MainThread) [custom_components.alarmo.sensors] async_sensor_state_changed was executed
2023-09-11 09:52:14.984 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.lumi_lumi_sensor_magnet_opening changed: old_state=closed, new_state=open
2023-09-11 09:52:14.985 INFO (MainThread) [custom_components.alarmo.sensors] Alarm is triggered due to sensor: binary_sensor.lumi_lumi_sensor_magnet_opening
2023-09-11 09:52:14.985 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.alarmo was updated from armed_home to triggered
2023-09-11 09:52:14.988 INFO (MainThread) [custom_components.alarmo.alarm_control_panel] Alarm is triggered!
2023-09-11 09:52:14.995 DEBUG (SyncWorker_8) [custom_components.alarmo.sensors] Stop listening to state changes of the sensors
2023-09-11 09:52:14.996 DEBUG (SyncWorker_8) [custom_components.alarmo.sensors] Start watching for state changes of the following sensors: binary_sensor.lumi_lumi_sensor_magnet_opening,binary_sensor.garage_door
2023-09-11 09:52:14.998 DEBUG (MainThread) [custom_components.alarmo.automations] state of alarm_control_panel.alarmo is updated from armed_home to triggered
2023-09-11 09:52:14.998 DEBUG (MainThread) [custom_components.alarmo.automations] Executing automation<PHONE_NUMBER>
2023-09-11 09:52:18.162 DEBUG (MainThread) [custom_components.alarmo.sensors] async_sensor_state_changed was executed
2023-09-11 09:52:18.162 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.lumi_lumi_sensor_magnet_opening changed: old_state=open, new_state=closed
2023-09-11 09:53:14.988 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] async_trigger_timer_finished
2023-09-11 09:53:14.989 INFO (MainThread) [custom_components.alarmo.alarm_control_panel] Alarm 'Alarmo' is armed (armed_home).
2023-09-11 09:53:14.989 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.alarmo was updated from triggered to armed_home
2023-09-11 09:53:14.992 DEBUG (SyncWorker_11) [custom_components.alarmo.sensors] Stop listening to state changes of the sensors
2023-09-11 09:53:14.992 DEBUG (SyncWorker_11) [custom_components.alarmo.sensors] Start watching for state changes of the following sensors: binary_sensor.lumi_lumi_sensor_magnet_opening,binary_sensor.garage_door
2023-09-11 09:53:14.995 DEBUG (MainThread) [custom_components.alarmo.automations] state of alarm_control_panel.alarmo is updated from triggered to armed_home

Hello, it seems the reason why the motion sensor doesn't trigger alarm is that for some reason it is absent in the list when alarmo changes state from triggered to armed.
The sequence of events:

+00 sec motion trigger alarm,  alarmo state was changed from armed_home to triggered.
+06 sec door was open
+15 sec door was closed
+60 sec trigger time expired, alarmo state was changed from triggered to armed_home. Motion sensor is not in the watch list.

2023-09-12 07:47:05.465 DEBUG (MainThread) [custom_components.alarmo.sensors] async_sensor_state_changed was executed
2023-09-12 07:47:05.466 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.motion_garage changed: old_state=closed, new_state=open
2023-09-12 07:47:05.466 INFO (MainThread) [custom_components.alarmo.sensors] Alarm is triggered due to sensor: binary_sensor.motion_garage
2023-09-12 07:47:05.467 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.alarmo was updated from armed_home to triggered
2023-09-12 07:47:05.469 DEBUG (SyncWorker_10) [custom_components.alarmo.sensors] Stop listening to state changes of the sensors
2023-09-12 07:47:05.470 DEBUG (SyncWorker_10) [custom_components.alarmo.sensors] Start watching for state changes of the following sensors: binary_sensor.lumi_lumi_sensor_magnet_opening,binary_sensor.motion_garage
2023-09-12 07:47:05.471 INFO (MainThread) [custom_components.alarmo.alarm_control_panel] Alarm is triggered!
2023-09-12 07:47:05.475 DEBUG (MainThread) [custom_components.alarmo.automations] state of alarm_control_panel.alarmo is updated from armed_home to triggered
2023-09-12 07:47:05.476 DEBUG (MainThread) [custom_components.alarmo.automations] Executing automation<PHONE_NUMBER>
2023-09-12 07:47:11.380 DEBUG (MainThread) [custom_components.alarmo.sensors] async_sensor_state_changed was executed
2023-09-12 07:47:11.380 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.lumi_lumi_sensor_magnet_opening changed: old_state=closed, new_state=open
2023-09-12 07:47:20.250 DEBUG (MainThread) [custom_components.alarmo.sensors] async_sensor_state_changed was executed
2023-09-12 07:47:20.251 DEBUG (MainThread) [custom_components.alarmo.sensors] entity binary_sensor.lumi_lumi_sensor_magnet_opening changed: old_state=open, new_state=closed
2023-09-12 07:48:05.472 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] async_trigger_timer_finished
2023-09-12 07:48:05.473 INFO (MainThread) [custom_components.alarmo.alarm_control_panel] Alarm 'Alarmo' is armed (armed_home).
2023-09-12 07:48:05.473 DEBUG (MainThread) [custom_components.alarmo.alarm_control_panel] entity alarm_control_panel.alarmo was updated from triggered to armed_home
2023-09-12 07:48:05.476 DEBUG (SyncWorker_5) [custom_components.alarmo.sensors] Stop listening to state changes of the sensors
2023-09-12 07:48:05.477 DEBUG (SyncWorker_5) [custom_components.alarmo.sensors] Start watching for state changes of the following sensors: binary_sensor.lumi_lumi_sensor_magnet_opening
2023-09-12 07:48:05.478 DEBUG (MainThread) [custom_components.alarmo.automations] state of alarm_control_panel.alarmo is updated from triggered to armed_home

@froloffw7 Thanks a lot for helping out with this!
I think you found some valuable info that may very well explain the bug that is investigated here.
Some important remark to be made here:
When Alarmo reverts to the armed state after being triggered, he does so in force.
This means that any sensors which prevent the (re-)arming will become bypassed.
This is done since it otherwise the arming would fail and the alarm becomes disarmed.
I thought it would be better to have part of the alarm restored than to have it remain disarmed.
But perhaps this behaviour should have been explicitly documented.
From your logging and the previous screenshot of the history, I assume that this has happened for the motion sensor.
The questions that remain are:

Is the bypassing actually what happened? Perhaps you could repeat your test and take note of the bypassed_sensors property of the alarm entity?
Is the bypassing needed? Could you share a screenshot of the settings of this sensor within Alarmo? If the 'Allow open initially' setting was set, I'd say the sensor has been falsely bypassed: this would be a bug.
Is the bypassing desirable? Apparently the current behaviour is not what is expected (unintuitive), so perhaps it should be changed. I am open to discuss some improvement to the behaviour.

@sokarovski @deadly667 Could you confirm whether the automatic bypassing behaviour when returning to armed state may explain your observations? If so, how would you expect Alarmo to perform the re-arming?

@sokarovski @deadly667 Could you confirm whether the automatic bypassing behaviour when returning to armed state may explain your observations? If so, how would you expect Alarmo to perform the re-arming?

@nielsfaber yes, if does explain.
I did a test where i went to the garage and left immediately. Doing only one trigger per day. Alarmo was working flawlessly for more than two weeks. So this tells me it is not time constraint.  This only happens when i am into the garage working for hours. I am guessing that it is happening when the PIR sensor is still triggered but Alarmo tries to go in armed state after the triggered state.
Although that is very strange scenario caused by me being lazy to disarm the alarm. I can see a scenario for example when a thief would be constantly moving in your house and you will receive only one notification.
My suggested scenario will be if Alarmo want to go into Armed state and finds out that all sensors are not clear, it should stay for another "Trigger Time" in the triggered state, and agian, and agian, until all sensors are clear. Or maybe it should re-enter the triggered state and send you another notification.

Sorry, I don't understand the meaning of bypassed_sensors property. Can you please point me how and were to check this?
Attaching screenshot with motion sensor Alarmo settings.

Is it possible to implement the similar algorithm like "Allow open initially: Open state while arming is ignored (subsequent sensor activation will trigger alarm)" instead of iteration with "Trigger Time" delay, as iteration may create some other issues which will be difficult to catch and debug.

@sokarovski

My suggested scenario will be if Alarmo want to go into Armed state and finds out that all sensors are not clear, it should stay for another "Trigger Time" in the triggered state, and agian, and agian, until all sensors are clear. Or maybe it should re-enter the triggered state and send you another notification.

Thanks for the idea.
However, I don't think this is the best choice, since many users configure a siren to be ringing whilst the system is in triggered state.
The purpose of the 'trigger time' is to determine the amount of time the siren should be ringing. Having the system repeat the triggered state for longer time would likely upset neighbours.
@froloffw7

Sorry, I don't understand the meaning of bypassed_sensors property. Can you please point me how and were to check this?

The bypassed sensors will be listed here (if any):

It is clear to me now that the user may not be aware of this property, and assumes all sensors are working OK when the system is armed.

Is it possible to implement the similar algorithm like "Allow open initially: Open state while arming is ignored (subsequent sensor activation will trigger alarm)"

Yes, this should be already in place. But you will need to enable this setting:

This gives Alarmo permission to ignore the initial state, so the arming (and also re-arming after triggering) would not fail, and the sensor will still activate the alarm after a next off-on state transition.
I think this already works as desired, if the setting is applied the motion sensor would not be added to the bypassed list after re-arming.
I am now planning to remove the automatic bypassing.
As a result of this change the arming would simply fail if any sensors are still open, the alarm would become disarmed. User intervention would be before the system can be armed again.
It is the more conservative approach but provide the user awareness of the situation.
As mentioned before, the motion sensors would not prevent the re-arming IF the "allow open initially" setting would be set.

Sorry, for the delay. I did some more tests with different settings.
It seems that enabling "Allow open initially" doesn't work in this case,  as I still have events missed with Alarmo.
I suppose that this setting should cause that appropriate sensor (binary_sensor.motion_garage in my case) should leave the "bypassed_sensors" list, when condition meet (no motion), but it doesn't.
Also I tried to increase trigger time and this didn't help as well.
If you plan to do some related changes, I have a proposal:
it could be better to have some setting like Siren time, separated from Trigger time.

I just made the aforementioned change of not bypassing open sensors when re-arming after triggering.
In my testing the 'allow open initially' setting for motion sensors still applies, i.e. a sensor with the setting may be still active when re-arming the alarm, it will not cause the re-arming to fail.
I will let you know when the change is released in a new version.

v1.9.11 is released which no longer bypasses the sensors when re-arming the alarm.
I will close this issue since this was found to be root cause of the problem.
If you still experience problems after updating, please let me know, we can reopen the case if needed.


[W5.7][F10-3]Dong SiJi

Changed find command to be not case sensitive.

Good job in making the find command not case sensitive. This is really a really useful feature in production code.

closed


Add durability to delete

When running
model.delete()

you should be able to provide durability, which is present in the python rethinkdb driver:
table.delete([durability="hard", return_changes=False]) → object
selection.delete([durability="hard", return_changes=False]) → object
singleSelection.delete([durability="hard", return_changes=False]) → object

(durability: possible values are hard and soft)
and when fetching results:
model.get_all()
anything with a soft delete is not included (and the same with any joined results)

Adding durability only to delete won't keep the interface transparent, since durability may be provided to several other operations as well.
One idea may be to provide an option for a model which will set the durability for the whole table. But then people may want to run part of their queries using a different durability.
Finally, since associations are at stake, how can you make sure that an associated record, soft written, can be safely used in operations on the parent model without losing data or corrupting the parent link? You could use sync, but that would make queries harder to implement.
Is there any specific use case for your proposal? Because if it is only a side wish, you could always build the query yourself and use whatever durability you wish (User.get(...).delete(durability='soft').run()).

Sorry. You can ignore this issue, please delete it.

No, don't be sorry. I appreciate any feedback and I'm trying to implement whatever you guys find necessary. For the above I was questioning whether it's worth it since you can, for exceptional cases, use the normal ReQL syntax directly on the model.
If this is really needed, I believe putting a table option would be the cleanest solution, although it doesn't solve all possible cases.
Will keep this open and will mark as a discussion, maybe there are others that need durability too.

Closing this one since it didn't get more comments. But feel free to reopen if there's something more to add!


Modules, TXM_MODULE_MEMORY_PROTECTION and TX_ENABLE_STACK_CHECKING bug?

Hi guys, I'm playing with the modules and found some interesting things:
Abstract:
It looks that if:
TXM_MODULE_MEMORY_PROTECTION and TX_ENABLE_STACK_CHECKING are enabled then in the tx_thread_system_suspend.c the kernel stack (which is not prepared for stack checking) is checked with the macro TX_THREAD_STACK_CHECK and cause the crash.
In TX_THREAD_STACK_CHECK macro, for modules, thread_ptr->tx_thread_module_stack_end should be used instead of thread_ptr->tx_thread_stack_end.
Investigation:
Initial:
TX_ENABLE_STACK_CHECKING 1
TXM_MODULE_MEMORY_PROTECTION 1
The creation of the "Module Start Thread":
In file txm_module_manager_create.c:
At the entry:
CHAR *name_ptr is "Module Start Thread"
VOID *stack_start is 0x400 8800
ULONG stack_size is 512.

Some basic stuff is checked, and then we get to the part of creating the stack.

The memory stack is filled by TX_MEMSET(stack_start, ((UCHAR) TX_STACK_FILL), stack_size);

Because TX_ENABLE_STACK_CHECKING is enabled, then we prepare the module stack:

stack_start is aligned, in this case it stays as it was (0x0400 8800).
stack_size is reduced by 4 bytes and the last 4 bytes of the stack are 0xEFEFEFEF.

The stack size is reduced again:

    /* Allocate the thread entry information at the top of thread's stack - Leaving one
       ULONG worth of 0xEF pattern between the actual stack and the entry info structure.  */

    stack_size =  stack_size - (sizeof(TXM_MODULE_THREAD_ENTRY_INFO) + (3*sizeof(ULONG)));

After that, the stack_size is 448 bytes.

Then we enter the TXM_MODULE_MEMORY_PROTECTION section (txm_module_manager_thread_create.c:312):

New memory is allocated using: status = _txm_module_manager_object_allocate((VOID **) &(thread_ptr -> tx_thread_module_kernel_stack_start), TXM_MODULE_KERNEL_STACK_SIZE, module_instance);

The thread_ptr->tx_thread_module_kernel_stack_start is set to: 0x400 6788

The TXM_MODULE_KERNEL_STACK_SIZE is 768.

The newly allocated memory is filled with pattern: TX_MEMSET(thread_ptr -> tx_thread_module_kernel_stack_start, ((UCHAR) TX_STACK_FILL), TXM_MODULE_KERNEL_STACK_SIZE);

After this, in memory there is 768 bytes of 0xEF value.

The thread_ptr->tx_thread_module_kernel_stack_end is aligned. (But next, the stack size is set to TXM_MODULE_KERNEL_STACK_SIZE instead of (tx_thread_module_kernel_stack_end - tx_thread_module_kernel_stack_start [another potential BUG?]).

Then the thread_ptr->tx_thread_module_kernel_stack_end takes value: 0x0400 6A88

THE KERNEL STACK IS NOT PREPARED FOR TX_THREAD_STACK_CHECK.

No more surprises till the end of the function.

At the end of the functions there are the following stacks values in the thread_ptr:
tx_thread_name is "Module Start Thread"
tx_thread_stack_start is 0x0400 8800
tx_thread_stack_end is 0x0400 89BF
tx_thread_stack_size is 448
tx_thread_module_stack_start is 0x0400 8800
tx_thread_module_stack_end is 0x0400 89BF
tx_thread_module_stack_size is 448
tx_thread_module_kernel_stack_start is 0x0400 6788
tx_thread_module_kernel_stack_end is 0x0400 6A88
tx_thread_module_kernel_stack_size is 768
Switching of the stacks
Then in the tx_thread_schedule.S the following code is executed:
    /* Switch to the module thread's kernel stack */
    LDR     r0, [r2, #0xA8]                         // Load the module kernel stack end
#ifndef TXM_MODULE_KERNEL_STACK_MAINTENANCE_DISABLE
    LDR     r1, [r2, #0xA4]                         // Load the module kernel stack start
    LDR     r3, [r2, #0xAC]                         // Load the module kernel stack size
    STR     r1, [r2, #12]                           // Set stack start
    STR     r0, [r2, #16]                           // Set stack end
    STR     r3, [r2, #20]                           // Set stack size
#endif

And the thread stack (tx_thread_stack_start) is switched to module thread's kernel stack (tx_thread_module_kernel_stack_start).
Checking the stack before suspend
And some ticks later...
In the tx_thread_system_suspend.c, the "Module Start Thread" is going to be suspended but:
thread_ptr->tx_thread_stack_start is 0x0400 6788 (position of the kernel stack)
thread_ptr->tx_thread_stack_end is 0x0400 6A88 (end position of the kernel stack)
thread_ptr->tx_thread_stack_size is 768.
Then TX_THREAD_STACK_CHECK(thread_ptr) is performed and *((ULONG *) (((UCHAR *) (thread_ptr)->tx_thread_stack_end) + 1)) != TX_STACK_FILL) is not true because the kernel stack has no 0xef at the end, because it was not prepared for TX_THREAD_STACK_CHECK.
Probably the thread_ptr->tx_thread_module_stack_end should be used instead of thread_ptr->tx_thread_stack_end.
Some other interesting points:

The memory in the TXM_MODULE_MEMORY_PROTECTION shouldnt be filled using the calculated: thread_ptr->tx_thread_module_kernel_stack_end - thread_ptr->tx_thread_module_kernel_stack_start AFTER alligning of the end of stack instead of the const TXM_MODULE_KERNEL_STACK_SIZE?

Stack size shouldn't be calculated using tx_thread_module_kernel_stack_end - tx_thread_module_kernel_stack_start after alignment instead of TXM_MODULE_KERNEL_STACK_SIZE?

Did your suggestions above resolve the stack checking issue using ThreadX with Modules? It sounds like stack checking for modules needs to be different than normal stack checking for ThreadX and so introduce a specific stack checking flag for ThreadX with modules. Is that right? Does it work now? Add a flag to make the adjustments for modules?

Modules has never supported the stack checking feature, so running into these issues that you are seeing is expected.
Let me address some points you made:

The module thread stack size is reduced by the ENTRY_INFO struct. This is mentioned in the second note here: https://docs.microsoft.com/en-us/azure/rtos/threadx-modules/chapter2. We should add this note to the txm_thread_create.c file.

tx_thread_module_kernel_stack_size isn't used anywhere other than in txm_module_manager_thread_reset.c and some RTOS-aware debuggers to show the stack size. This value has no effect on runtime behavior. But yes, we should do the calculation you are suggesting.

Because the stack checking feature was never supported by modules, we did not prepare the kernel stack.

For both of your questions: yes, we should do the calculation instead of using TXM_MODULE_KERNEL_STACK_SIZE.

Thanks @goldscott for the fast answer! In this case, I have a few more questions:

If the modules has never supported the stack checking, then why in the txm_module_manager_thread_create.c:279 (where module threads are created) there IS a section which enable the stack checking and prepare the module for this?

In the tx_thread_system_suspend.c if TX_ENABLE_STACK_CHECKING is defined, there is no distinction between module thread or ThreadX thread, so @ascheurer has right in his comment.

Is there any dedicated way to check if the current thread is a module or not? For now - it can be done by checking the module specific part of the thread_ptr, ex. if thread_ptr->tx_thread_module_instance_ptr is not NULL.

Because in the tx_thread_system_suspend.c if the TX_ENABLE_STACK_CHECKING is enabled there is no distinction if the current thread is module or not, then the conclusion is that if we have any module in our system, then stack checking should be disabled globally?

I've made a simple workaround which works (at least in tx_thread_system_suspend.c:114).

#ifdef TX_ENABLE_STACK_CHECKING
    if (thread_ptr)
    {
        if (thread_ptr->tx_thread_module_instance_ptr == NULL)
        {
            TX_THREAD_STACK_CHECK(thread_ptr)
        }
        else
        {
            TX_INTERRUPT_SAVE_AREA
                TX_DISABLE
                if (((thread_ptr)) && ((thread_ptr)->tx_thread_id == TX_THREAD_ID))
                {
                    if ((*((ULONG *) (thread_ptr)->tx_thread_module_stack_start) != TX_STACK_FILL) ||
                        (*((ULONG *) (((UCHAR *) (thread_ptr)->tx_thread_module_stack_end) + 1)) != TX_STACK_FILL))
                    {
                        TX_RESTORE
                            _tx_thread_stack_error_handler((thread_ptr));
                        TX_DISABLE
                    }
                }
                TX_RESTORE
        }
    }
#endif

instead of
#ifdef TX_ENABLE_STACK_CHECKING
TX_THREAD_STACK_CHECK(thread_ptr)
#endif

Iv'e tried to make more complete solution, but there is no such thing as thread_ptr->tx_thread_module_stack_highest, so in case of modules now we can only check if there is no stack override.

Hi @mwolosewicz,
No worries!

txm_module_manager_thread_create was derived from tx_thread_create, so that stack checking was there to begin with.

Correct. tx_thread_suspend (more specifically the TX_THREAD_STACK_CHECK macro) has no knowledge whether a thread is normal or from a module.

That is how to check if a thread is owned by a module. There is no "dedicated way" such as an API.

Correct, you should not use stack checking if you are using modules. The stack checking built into ThreadX does not currently know how to handle a module thread (which actually has two stacks).

Your workaround is a good start. We'd have to #define a modified TX_THREAD_STACK_CHECK (probably in tx_port.h) and add that thread struct member (tx_thread_module_stack_highest_ptr).

Stack checking support for Modules has been on my to-do list for a while. If this is a feature you'd like to use, I'll bump up its priority.

Hi @goldscott,
thanks for great explanation. I'm not sure if the stack checking is crucial for me right now. I won't affect your priorities, but in general I believe that in a safety critical system it may be important.
I've asked the questions because I wasn't sure If there is a bug, or my understanding of the code base is too shallow.
Now everything is clear for me.
Great, thanks!

Hi @goldscott,
The stack checking feature is useful and did flag an overrun in the non-module use of threadx -  it would be useful and consistent to support stack checking with threadx with modules and as you mentioned as a next step. Suggest include a clearer set of calculations on how the stack is managed (see above "yes, we should do the calculation instead of using TXM_MODULE_KERNEL_STACK_SIZE). For now if modules do not support stack checking,making this more clear now would be helpful as it does look like stack checking with modules is supported - a comment or macro would be helpful to make this clear.
Stack checking within modules would be useful - it's a feature that would certainly get used.

Hi @ascheurer - I'll bump up the priority of adding stack checking to modules. It should be pretty easy. A couple "limitations" I see is (1) only the kernel/manager is going to do the stack check and error handling (i.e. no error handling on the module side, but that is probably a good thing) and (2) modules can manipulate their stacks at will, thus stack checking may not be accurate.
I'll keep this ticket open and close it once stack checking is supported in modules. We have a new release coming at the end of April, so I'm not sure we'll be able to get this done in time. It will likely be in the July release.

Stack checking is supported in this commit. Closing.

TX_ENABLE_STACK_CHECKING is not implemented in Modules. The commit that @TiejunMS references is a bug fix.


[ZT] WARP logs (single page version)

Preview: https://91d41063.cloudflare-docs-7ou.pages.dev/cloudflare-one/connections/connect-devices/warp/warp-logs/

most recent updates are in #7518


Write a JavaScript program to find digital root of a number

Description
Write a JavaScript program to find digital root of a number
Digital root of a number is the recursive sum of its digits until we get a single digit number.
Input  : 1234
Output : 1

How to contribute

Save the solution in program/FindDigitalRootOfANumber.js file
Add FindDigitalRootOfANumber.js file in find-digital-root-of-a-number folder

!assign


fix #241

This fixes #241, the issue was when the last value had padded zeros.
Note that empress alone works fine but when combining with Emperor we get:
k
However, not fixing here as I think that falls out of the scope of this PR.

@antgonza Would you mind explaining what the issue was? I am not able to understand from the code changes. Also, I pulled down your branch and was able to load a tandem plot with a rarefied and with an unrarefied table (for the moving pictures dataset). I don't know what might be causing the error you posted.

Sure. The issue/fix is in the new tests, basically when we have padded zeros in the last number, in the test -> 0, 0, 0, 0, 1, 1, 1; the original code didn't deal with them and simply returned a 7. Now, it returns the padded zeros and the 7 -> 0, 0, 0, 0, 7.

The Error is from Emperor, my guess: I'm using an old version. Thank you for checking!

Thanks @antgonza!


Set the scripts dir to readonly after init

Changes

Make the script volume mount read-only for all mounts excluding the init container that creates the scripts
This resolves issue #4160 and prevents overwriting the scripts from subsequent steps leading to anomalous, obscure, or dangerous results.
I made these changes a while ago before the debug scripts volume was added. I added an extra commit to deal with debug scripts too. I've ran the unit tests and I've deployed with ko and done some normal runs (using the tests from catalog) in a k3d cluster but I'm not very familiar with this debug scripts feature so some deeper testing might be necessary.
Edit: the debug scripts need to be written to each step like /tekton/tools with it's post/wait files
/kind bug
Submitter Checklist
As the author of this PR, please check off the items in this checklist:

[X] Docs included if any changes are user facing
[X] Tests included if any functionality added or changed
[X] Follows the commit message standard
[X] Meets the Tekton contributor standards (including
functionality, content, code)
[X] Release notes block below has been filled in or deleted (only if no user facing changes)

Release Notes

Note: I can modify the release-note to "action required" if we think someone might actually be overwriting the scripts in their use of tekton
Their resolution action would be to either an alternative mentioned at the bottom of #4160 or to mount their own volume to write other scripts to
Mount script workspace as readonly

/ok-to-test
/approve

Ok, my unit tests were passing but that was just a cached result :confused:
I've dropped the debug scripts part

/retest

/lgtm

I can't at a glance tell what the cause of the failure is. Is this known flakeyness?

Here's the data race log in full:
==================
WARNING: DATA RACE
Read at 0x00c000aa0943 by goroutine 235:
  testing.(*common).logDepth()
      /usr/local/go/src/testing/testing.go:753 +0xa6
  testing.(*common).log()
      /usr/local/go/src/testing/testing.go:746 +0x8f
  testing.(*common).Logf()
      /usr/local/go/src/testing/testing.go:792 +0x21
  testing.(*T).Logf()
      <autogenerated>:1 +0x75
  go.uber.org/zap/zaptest.testingWriter.Write()
      /home/prow/go/src/github.com/tektoncd/pipeline/vendor/go.uber.org/zap/zaptest/logger.go:130 +0x153
  go.uber.org/zap/zaptest.(*testingWriter).Write()
      <autogenerated>:1 +0xad
  go.uber.org/zap/zapcore.(*ioCore).Write()
      /home/prow/go/src/github.com/tektoncd/pipeline/vendor/go.uber.org/zap/zapcore/core.go:90 +0x1e7
  go.uber.org/zap/zapcore.(*CheckedEntry).Write()
      /home/prow/go/src/github.com/tektoncd/pipeline/vendor/go.uber.org/zap/zapcore/entry.go:220 +0x1f1
  go.uber.org/zap.(*SugaredLogger).log()
      /home/prow/go/src/github.com/tektoncd/pipeline/vendor/go.uber.org/zap/sugar.go:227 +0x154
  go.uber.org/zap.(*SugaredLogger).Warnf()
      /home/prow/go/src/github.com/tektoncd/pipeline/vendor/go.uber.org/zap/sugar.go:143 +0x1ab
  github.com/tektoncd/pipeline/pkg/reconciler/taskrun.(*Reconciler).ReconcileKind.func1()
      /home/prow/go/src/github.com/tektoncd/pipeline/pkg/reconciler/taskrun/taskrun.go:144 +0x12b

Previous write at 0x00c000aa0943 by goroutine 250:
  testing.tRunner.func1()
      /usr/local/go/src/testing/testing.go:1180 +0x52c
  testing.tRunner()
      /usr/local/go/src/testing/testing.go:1197 +0x22a

Goroutine 235 (running) created at:
  github.com/tektoncd/pipeline/pkg/reconciler/taskrun.(*Reconciler).ReconcileKind()
      /home/prow/go/src/github.com/tektoncd/pipeline/pkg/reconciler/taskrun/taskrun.go:131 +0x647
  github.com/tektoncd/pipeline/pkg/client/injection/reconciler/pipeline/v1beta1/taskrun.Interface.ReconcileKind-fm()
      /home/prow/go/src/github.com/tektoncd/pipeline/pkg/client/injection/reconciler/pipeline/v1beta1/taskrun/reconciler.go:53 +0x79
  github.com/tektoncd/pipeline/pkg/client/injection/reconciler/pipeline/v1beta1/taskrun.(*reconcilerImpl).Reconcile()
      /home/prow/go/src/github.com/tektoncd/pipeline/pkg/client/injection/reconciler/pipeline/v1beta1/taskrun/reconciler.go:246 +0x18ee
  github.com/tektoncd/pipeline/pkg/reconciler/taskrun.TestReconcileOnCancelledTaskRun()
      /home/prow/go/src/github.com/tektoncd/pipeline/pkg/reconciler/taskrun/taskrun_test.go:2212 +0x1353
  testing.tRunner()
      /usr/local/go/src/testing/testing.go:1193 +0x202

Goroutine 250 (running) created at:
  testing.(*T).Run()
      /usr/local/go/src/testing/testing.go:1238 +0x5d7
  testing.runTests.func1()
      /usr/local/go/src/testing/testing.go:1511 +0xa6
  testing.tRunner()
      /usr/local/go/src/testing/testing.go:1193 +0x202
  testing.runTests()
      /usr/local/go/src/testing/testing.go:1509 +0x612
  testing.(*M).Run()
      /usr/local/go/src/testing/testing.go:1417 +0x3b3
  main.main()
      _testmain.go:121 +0x236
==================

But I don't see how your change has caused this. 😕

/test tekton-pipeline-unit-tests

Looks like the UT race was a flake :/
/test pull-tekton-pipeline-alpha-integration-tests


NO-ISSUE rebase.py: python3

Recently we updated build_root image to one based on RHEL9 which ships python3 instead of python2. Change is needed to fix rebase procedure

/hold

Tested with rehearsal https://github.com/openshift/release/pull/39713
/unhold


fix(EU): force update

I realized that force update is not implemented or at least does not update any internal state. This implements the forced update
by first retrieving either the cached state or the full forced state (as bluelinky does) and then updates the internal properties from the pieced-together dict.
It also implements a _get_location method, cdnninjas is more fleshed out though

I hope these patches are integrated in the master branch soon.

Very nice work!
I'm using lib taken from https://github.com/jwefers/hyundai_kia_connect_api and I can confirm that it works perfectly.
I'm using with Domoticz plugin https://github.com/CreasolTech/domoticz-hyundai-kia and location/speed/odometer/... update perfectly, now. Hope this patch will be merged soon!

Hi, I found an issue when asking for vehicle refresh and the vehicle has data connection broken:
when I call
vm.force_refresh_all_vehicles_states()
after about 240s I get
hyundai_kia_connect_api - _get_location failed
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python3.9/dist-packages/hyundai_kia_connect_api/VehicleManager.py", line 80, in force_refresh_all_vehicles_states
self.force_refresh_vehicle_state(self.get_vehicle(vehicle_id))
File "/usr/local/lib/python3.9/dist-packages/hyundai_kia_connect_api/VehicleManager.py", line 84, in force_refresh_vehicle_state
self.api.force_refresh_vehicle_state(self.token, vehicle)
File "/usr/local/lib/python3.9/dist-packages/hyundai_kia_connect_api/KiaUvoApiEU.py", line 184, in force_refresh_vehicle_state
self._update_vehicle_properties(vehicle, state)
File "/usr/local/lib/python3.9/dist-packages/hyundai_kia_connect_api/KiaUvoApiEU.py", line 187, in _update_vehicle_properties
vehicle.last_updated_at = self.get_last_updated_at(
File "/usr/local/lib/python3.9/dist-packages/hyundai_kia_connect_api/KiaUvoApiEU.py", line 162, in get_last_updated_at
m = re.match(r"(\d{4})(\d{2})(\d{2})(\d{2})(\d{2})(\d{2})", value)
File "/usr/lib/python3.9/re.py", line 191, in match
return _compile(pattern, flags).match(string)
TypeError: expected string or bytes-like object

Thanks a lot

thanks for discovering :) i will read through it probably on the weekend. maybe simply using cdnninjas version (other pr) takes care of this already

Previously when we use this for the kia_uvo integration we call the get cached status after a force update.  I will take a closer look at this and provide feedback.

okay now that i read through it - i mean if the api simply does not respond sometimes - only thing we could do is add a timelimit for the request

I am getting back into this.  Taking a look I think this makes alot of sense.    I think next steps though is implementing and updating this for other regions.  I have alot going on with getting this API ready for prime time on the kia_uvo version 2.0 home assistant integration. Lots of commits coming.   Feel free to tweak this if you have time. If not I will get to it soon as this may be related to another bug I have in kia_uvo.

Hi,
unfortunately i am out till end of year. too many other responsibilities until then. but in january, i probably can spend time again


Cannot determine correct breakpoint from onDrop

When using ResponsiveGridLayout and onDrop there is no way to identify what the current breakpoint is. onDrop's params do not include a breakpoint, but include item props {x, y, w, h} which are associated with the breakpoint at the time the user dropped the external item (the current breakpoint). And the current breakpoint is managed by RGL and cannot easily be extracted.
This is an issue because the basic idea of onDrop is to add an item to the layout but it is unknown which of the breakpoints the item should be added to the layout of.
RGL should override the onDrop event to include breakpoint information in the callback's args, just like it does with onLayoutChange.
I have a few ideas on potential API, thoughts?

(elemParams: { x, y, w, h, e, breakpoint = currentBreakpoint } - Easy and backwards compatible
(elemParams: { [breakpoint]: { x, y, w, h, e } }) - Fits with layouts etc.
(elemParams: { x, y, w, h, e }, allElemParams: { [breakpoint]: { x, y, w, h } } - Fits in with onLayoutChange and is backwards compatible

Create a React.RefObject to obtain current breakpoint from RGL Component. That's all.

How do you suggest getting the current breakpoint from a ref? There is no public property/method for getting the current breakpoint?

import { Responsive as ResponsiveReactGridLayout } from "react-grid-layout";

class MyComponent extends Component {
  private ref : React.RefObject<any> = React.createRef();

  componentDidMount(){
    console.log('breakpoint',this.ref.current.state.breakpoint); // breakpoint here
  }

  render(){
    return(
     <ResponsiveReactGridLayout ref={this.ref}>
      ...
     </ResponsiveReactGridLayout>
    );
  }
}

This sample is using .tsx.
I hope it will be useful for you. =)

component.state.breakpoint is a private interface, it's not part of the API. That would be a hack rather than a solution.

I don't think so. But, I suppose, if you create a PR with this feature it will be welcome to this project.

I ran into this exact issue - I was really hoping to use onBreakpointChange to maintain the breakpoint state separately in a containing component, however onBreakpointChange does not appear to fire on initialization (react-grid-layout 1.3.0, React 16.8.6).
Oddly the "Drag from Outside" example seems to be able to correctly display the initial breakpoint, so I'm not sure what I'm missing. If I can get that initial breakpoint, I think I can easily work around the above issue.

I found my issue - we were using a different HOC from WidthProvider that behaved slightly differently, causing the initialization issue.
With that solved, if you run into the above issue, I recommend maintaining the breakpoint state using onBreakpointChange in your component state. Then you will be able to tell which breakpoint you need to replace onDrop.
Hope this helps someone!

const handleOnLayoutChange = (layout: Layout[], layouts: any) => {
setLayouts((prev:any) => {
return { ...prev, ...layouts };
});
};


Colours

the css file has been changed to stylesheets/.css because I haven't fully figured out compass' watch command.
css.css is now broken.


cleanup: use roles constants

Before we had to hard-code roles strings:
use Sensio\Bundle\FrameworkExtraBundle\Configuration\Security;
use Sensio\Bundle\FrameworkExtraBundle\Configuration\IsGranted;

class PostController extends Controller
{
    /**
     * @IsGranted("ROLE_ADMIN")
     *
     * or use @Security for more flexibility:
     *
     * @Security("is_granted('ROLE_ADMIN') and is_granted('ROLE_FRIENDLY_USER')")
     */
    public function index()
    {
        // ...
    }
}

But with attributes, can use constants. I find this cleaner. I have already used this on several projects and I didn't find drawbacks.

Could we use an Enum instead of constants? Would Enums work everywhere? Is it worth it or is it overengineering?

No we cannot. Roles are strings in Symfony, not an enum object.

You can use e.g. RoleEnum::USER->value (since PHP 8.1) in attributes and php code, bit IIRC not in Yaml.

You can use e.g. RoleEnum::USER->value (since PHP 8.1) in attributes and php code, bit IIRC not in Yaml.

With PHP 8.2 it will be OK, but we can't yet with 8.1:

Hello, is it OK for this PR? Or should we close it?

My opinion:

🟢 I like a lot using these constants in PHP files
🟡 I'm not entirely sure about injecting these constants in all Twig templates as global constants
🔴 I don't like how complicated this looks in the YAML file, especially in the security.yaml file

What do others think about this? Thanks.

I fully agree with @javiereguiluz' assessment.

🟢 I like a lot using these constants in PHP files

Me too, I wouldn't make those constants members of the User class though. In my projects, I usually have a final class Roles that holds those constants.

🟡 I'm not entirely sure about injecting these constants in all Twig templates as global constants

Me neither and I wouldn't do it tbh. We don't gain much here.

🔴 I don't like how complicated this looks in the YAML file, especially in the security.yaml file

Same. I would revert this as well.

Sure you can workaround the bad architecture by using RoleEnum::USER->value everywhere. But I would not recommend doing that in the demo as this would give the impression that using a enum for roles is a good idea, while this is an abuse of enums based on the fact that you need role strings anyway.

@stof but in this case we're not talking about enums. It's using PHP constants in YAML that looks too complicated to us. E.g. this change:
     role_hierarchy:
-        ROLE_ADMIN: ROLE_USER
+        !php/const App\Entity\User::ROLE_ADMIN: !php/const App\Entity\User::ROLE_USER

But in PHP files these constants look very nice.

Me too, I wouldn't make those constants members of the User class though. In my projects, I usually have a final class Roles that holds those constants.

But that looks weird to put this in a separated class. In this case we should use an enum (but we don't want too here). Having these constants in the User class is the more pragmatic way imho.

🟡 I'm not entirely sure about injecting these constants in all Twig templates as global constants
Me neither and I wouldn't do it tbh. We don't gain much here.

Actually, if we don't want to use a constant here, we could use a twig extension doing the job and making use of the PHP constant. But that's not as simple as using is_granted indeed.

🔴 I don't like how complicated this looks in the YAML file, especially in the security.yaml file

I agree it makes the YAML unreadable. I didn't even knew it was possible to do this, so let's revert this.

But that looks weird to put this in a separated class.

🤨 🤷🏻♂

It's merged now. Thanks!


Dont access to DB if the message is not supported

https://github.com/n0th1ng-else/voice-to-text-bot/pull/77


Missing models

Hi,
First of all many thanks for your incredibly exciting research and for publishing your code!
I recently tried to run your train_Point2Cyl script, however this seems to assume a models folder to be present in the root directory, containing model files (such as pointnet_extrusion). Unfortunately this folder is not yet part of the repository. Are you planning on publishing these models and if so, what would be the timeline?
Many thanks in advance for your reply!
Best regards,
Anthony

Hi Mika,
Thanks for updating your repo! All seems to work now :)
Thanks again,
Anthony


Accordian does not work in latest Carbon v5 due to issues with @carbon/styles

Accordian does not work in latest Carbon v5
Detailed description
I cannot seem to get the cds-accordion-item element to expand and collapse the content within the tag. I have found that the expanded property is set correctly, and the icon to indicate expanded ^ or collapsed v is changing, but the content within the tag is always displayed regardless if the accordian element is expanded or not.
it seems something changed between version 1.40.0 and 1.46.0 of the @carbon/styles package that broke the accordion functionality. If you use the latest version, 1.46.0, the content of cds-accordian-item is expanded all the time. @carbon/styles 1.40.0 behaves as expected.
Steps to reproduce the issue
Try opening according module with latest carbon angular component and carbon styles version.

Observed this issue recently, will have a fix out soon. Sorry for the delay!


Hide revision date for repo overview pages

Purpose

These overview pages are just snippets of the repo's README. However a page's revision date doesn't reflect its snippet's revision date. Thus, I propose that we hide the revision date for these files.
Resources

https://timvink.github.io/mkdocs-git-revision-date-localized-plugin/available-variables/#variables-for-overriding-themes

Or maybe we should remove this plugin outright, I don't think we're getting much value out of it.


bitwarden_rs-vault: 2.12.0c -> 2.12.0e

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools. This update was made based on information from https://github.com/dani-garcia/bw_web_builds/releases.
meta.description for bitwarden_rs-vault is: "Integrates the web vault into bitwarden_rs"
meta.homepage for bitwarden_rs-vault is: "https://github.com/dani-garcia/bw_web_builds"
Release on GitHub
Compare changes on GitHub

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

directory tree listing: https://gist.github.com/402bdde1826a14f66d9e4513cbe3d79c

du listing: https://gist.github.com/bea733773aa5fa3478335f08323cfb5b

Rebuild report (if merged into master) (click to expand)

4 total rebuild path(s)
1 package rebuild(s)
1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
1 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)
First fifty rebuilds by attrpath
bitwarden_rs-vault

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/1j4fcbn2rwfy2cmw6qc6a5azf3d689kw-bitwarden_rs-vault-2.12.0e \
  --option binary-caches 'https://cache.nixos.org/ https://r-ryantm.cachix.org/' \
  --option trusted-public-keys '
  r-ryantm.cachix.org-1:gkUbLkouDAyvBdpBX0JOdIiD2/DP1ldF3Z3Y6Gqcc4c=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(r-ryantm's Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A bitwarden_rs-vault https://github.com/r-ryantm/nixpkgs/archive/c282e36a22c4ba08af6ba4f0daa5a7cdc831b296.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/1j4fcbn2rwfy2cmw6qc6a5azf3d689kw-bitwarden_rs-vault-2.12.0e
ls -la /nix/store/1j4fcbn2rwfy2cmw6qc6a5azf3d689kw-bitwarden_rs-vault-2.12.0e/bin

cc @msteen for testing.

Yeah, this is broken… bitwarden_rs doesn't start with this. Before the path looked like this
ls /nix/store/zqkdqirhw6zyyyfkw91zg3pza70j6yhg-bitwarden_rs-vault-2.12.0c/share/bitwarden_rs/vault

app/         browserconfig.xml  duo-connector.html  fonts/   index.html  manifest.json  u2f-connector.html
app-id.json  connectors/        favicon.ico         images/  locales/    scripts/       version.json

After this, it's in a subfolder
ls /nix/store/nz016987lzm7amps9wchcwnydlnd90qz-bitwarden_rs-vault-2.12.0e/share/bitwarden_rs/vault

web-vault/

I'll open a PR to fix this.


Feature: No safety settings when using langchain_google_genai's ChatGoogleGenerativeAI

Feature request
The safety settings are there in the google_generativeai library are are not there in the langchain_google_genai library
The safety settings is an basically array of dictionaries passed when sending the prompt
Motivation
The problem with not having this is that when we use the ChatGoogleGenerativeAI model, if there is some kind of prompt which violate the basic safety settings then the model won't return with your answer
If we can change the safety settings and send it with the prompt to the model we could fix this issue
Your contribution
I am currently reading the code of the library and will raise a PR if i could fix the issue

I have a similar problem.
When I want to use genai.configure function to set something, but I don't know how to set these in the langchain_google_genai library.
And I find that the source code only deals with the setting of api_key,  genai.configure(api_key=google_api_key)

yes, it is quite frustrating because it triggers the safety warnings with most politics related text or pdfs, i am currently working on fixing it, will raise the PR once its done

just added the PR, will close the issue once its merged

Any updates?

Any updates ?

@Spritan and @rayanfer32
From the PR above, it looks like you can just add safety_settings=None when you initiate your langchain model. For example:
langchain_model = ChatGoogleGenerativeAI(
        model="gemini-pro", google_api_key=GOOGLE_API_KEY,
        safety_settings=None
    )

Google GenerativeAI is still missing the safety_settings which were added to VertexAI. Without any default values set Google GenerativeAI is prone to silently fail.
https://github.com/langchain-ai/langchain/pull/15344
https://github.com/langchain-ai/langchain/blob/master/libs/partners/google-genai/langchain_google_genai/llms.py

@ironerumi Thanks for letting me know! Yes, it seems fixed now. I can finally work with the official wrapper again 👍

It seems like this is still not working? I tried setting BLOCK_NONE for everything and it still won't invoke a proper response. It still returns "I am not able to answer that question... Would you like me to try something different?" I'm using below, which I think is close:
llm = ChatGoogleGenerativeAI(   model="gemini-pro",   temperature=0.7,   safety_settings={     HarmCategory.HARM_CATEGORY_DANGEROUS_CONTENT: HarmBlockThreshold.BLOCK_NONE,     HarmCategory.HARM_CATEGORY_SEXUALLY_EXPLICIT: HarmBlockThreshold.BLOCK_NONE,     HarmCategory.HARM_CATEGORY_HATE_SPEECH: HarmBlockThreshold.BLOCK_NONE,     HarmCategory.HARM_CATEGORY_HARASSMENT: HarmBlockThreshold.BLOCK_NONE,   }, )

It seems like this is still not working? I tried setting BLOCK_NONE for everything and it still won't invoke a proper response. It still returns "I am not able to answer that question... Would you like me to try something different?" I'm using below, which I think is close:
llm = ChatGoogleGenerativeAI( model="gemini-pro", temperature=0.7, safety_settings={ HarmCategory.HARM_CATEGORY_DANGEROUS_CONTENT: HarmBlockThreshold.BLOCK_NONE, HarmCategory.HARM_CATEGORY_SEXUALLY_EXPLICIT: HarmBlockThreshold.BLOCK_NONE, HarmCategory.HARM_CATEGORY_HATE_SPEECH: HarmBlockThreshold.BLOCK_NONE, HarmCategory.HARM_CATEGORY_HARASSMENT: HarmBlockThreshold.BLOCK_NONE, }, )

            HarmCategory.HARM_CATEGORY_SEXUALLY_EXPLICIT: HarmBlockThreshold.BLOCK_NONE,
            HarmCategory.HARM_CATEGORY_HATE_SPEECH: HarmBlockThreshold.BLOCK_NONE,
            HarmCategory.HARM_CATEGORY_HARASSMENT: HarmBlockThreshold.BLOCK_NONE,
            HarmCategory.HARM_CATEGORY_DANGEROUS_CONTENT: HarmBlockThreshold.BLOCK_NONE,
        }

That's basically what I have too and unfortunately Google will still flat out refuse some queries. I highly recommend you try Langsmith to trace these calls so you can precisely narrow down the server response and add a fallback mechanism within your chain so it doesn't stop the execution. If you increase debugging it should show more helpful errors (but sometimes it will just fail). You could also try using GoogleGenerativeAI instead.

I am curious about this as well. I have tried using both
llm = ChatGoogleGenerativeAI(safety_settings=None,model="gemini-pro",temperature=0.7, top_p=0.85)
and the enumerated values and both times is fails. If anyone has a solution to this please let us know

It's just my assumption that when lowering the threshold Google will response more sensitive contents, but even if when set to None it won't response truly harmful contents like describe how to create a bomb in the kitchen or something.
So while asking those truly harmful questions, the difference when setting the threshold or not, will be whether you will get an answer like "I cannot tell you that" or the return content will be empty.

'BLOCK NONE' is restricted, try the following settings
import google.generativeai as genai
safety_settings={
genai.types.HarmCategory.HARM_CATEGORY_DANGEROUS_CONTENT: genai.types.HarmBlockThreshold.BLOCK_ONLY_HIGH,
genai.types.HarmCategory.HARM_CATEGORY_HARASSMENT: genai.types.HarmBlockThreshold.BLOCK_ONLY_HIGH,
genai.types.HarmCategory.HARM_CATEGORY_HATE_SPEECH: genai.types.HarmBlockThreshold.BLOCK_ONLY_HIGH,
genai.types.HarmCategory.HARM_CATEGORY_SEXUALLY_EXPLICIT: genai.types.HarmBlockThreshold.BLOCK_ONLY_HIGH
}

Neither BLOC_NONE, nor BLOCK_ONLY_HIGH are working

yea, even I set block only high it will still block the MEDIUM content
gemini_safety_setting: dict = {}
            for category in HarmCategory:
                gemini_safety_setting[category] = HarmBlockThreshold.BLOCK_ONLY_HIGH
            # Initialize the GoogleGenerativeAI instance with the API key
            self.ai = ChatGoogleGenerativeAI(
                google_api_key=google_api_key,
                model=os.environ.get('GEMINI_MODEL'),
                safety_settings=gemini_safety_setting
            )

return msg
google.generativeai.types.generation_types.StopCandidateException: index: 0
finish_reason: SAFETY
safety_ratings {
  category: HARM_CATEGORY_SEXUALLY_EXPLICIT
  probability: MEDIUM
}
safety_ratings {
  category: HARM_CATEGORY_HATE_SPEECH
  probability: NEGLIGIBLE
}
safety_ratings {
  category: HARM_CATEGORY_HARASSMENT
  probability: NEGLIGIBLE
}
safety_ratings {
  category: HARM_CATEGORY_DANGEROUS_CONTENT
  probability: NEGLIGIBLE
}

we really want this setting work very urgent, thanks

I also noticed the parameter on ChatGoogleGenerativeAI is ignored. However, you can pass safety_settings to your model invoke method (or using model.bind(...) when chaining with LCEL) and it works fine.

Facing this issue too. Was getting empty responses even after passing necessary safety_settings to ChatGoogleGenerativeAI or its respective chain's invoke method. After some digging I figured the kwargs is lost somewhere in the propagation of calls, Resulting in None safety_settings at ChatGoogleGenerativeAI._generate
I'm patching this with a work around or now, will update if i get something better
# store the original method
og_generate = ChatGoogleGenerativeAI._generate

# patch
ChatGoogleGenerativeAI._generate = partial(self.llm._generate, safety_settings=self.safety_settings)

chain = RetrievalQAWithSourcesChain(...)
result = chain.invoke({"question": question, ...})

# revert the patch
ChatGoogleGenerativeAI._generate = og_generate

@PrajwalPrashanth brilliant, you saved my day!

@PrajwalPrashanth brilliant, you saved my day too!
One thing, when using stream:
llm =  ChatGoogleGenerativeAI(...)
safety_settings = {
    HarmCategory.HARM_CATEGORY_DANGEROUS_CONTENT: HarmBlockThreshold.BLOCK_NONE
}

# store the original method
og_stream = ChatGoogleGenerativeAI._stream

# patch
ChatGoogleGenerativeAI._generate = partial(llm._stream, safety_settings=safety_settings)

result = llm.stream({"question": question, ...})

# revert the patch
ChatGoogleGenerativeAI._stream = og_stream

Facing this issue too. Was getting empty responses even after passing necessary safety_settings to ChatGoogleGenerativeAI or its respective chain's invoke method. After some digging I figured the kwargs is lost somewhere in the propagation of calls, Resulting in None safety_settings at ChatGoogleGenerativeAI._generate我也遇到了这个问题。即使在将必要的 safety_settings 传递给 ChatGoogleGenerativeAI 或其相应链的调用方法后，也一直收到空响应。经过一番调查，我发现 kwargs 在调用传播过程中丢失了，导致 ChatGoogleGenerativeAI._generate 处的 safety_settings 为 None。
Work around for now, patching with explicit setting of safety_settings. Will update if I figure out better目前采用变通方法，通过显式设置 safety_settings 来修补。如果找到更好的方法，我会更新。
llm =  ChatGoogleGenerativeAI(...)
safety_settings = {
            HarmCategory.HARM_CATEGORY_DANGEROUS_CONTENT: HarmBlockThreshold.BLOCK_NONE
        }

# store the original method
og_generate = ChatGoogleGenerativeAI._generate

# patch
ChatGoogleGenerativeAI._generate = partial(llm._generate, safety_settings=safety_settings)

chain = RetrievalQAWithSourcesChain(...)
result = chain.invoke({"question": question, ...})

# revert the patch
ChatGoogleGenerativeAI._generate = og_generate

Remember that the HarmCategory should be imported by
from google.generativeai.types import HarmCategory, HarmBlockThreshold

instead of
from langchain_google_vertexai import HarmBlockThreshold, HarmCategory

@PrajwalPrashanth Thank so much, you saved my day!


Values for prepare amplicon sequencing run appear unpredictable

The sample amounts and total concentration appears inconsistent when the same values are presented: the same DNA concentration does not appear to result in the same sample or total concentration values.

@wasade Unless the gif above is misleading me, the focus remained on the Test sequencing pool 1 DNA conc (ng/ul) box the entire time the changes above were being made.  The other values are updated when the focus moves OFF of one of those boxes--such as when the clicks into another box (if there is more than one pool included) or goes to click on the "Pool" button.  See attached gif:

Oh, I see now. It looks like it updates on the first click after gaining focus, and then again once focus is lost, but not with clicks following the first one when under focus. If this is desired then we should close the issue

Hahahaha ... I think "desired" might be an overstatement :)  I'm fine with keeping this as an issue (because if it confused you it will confuse others too!) but will change the description and priority to reflect that it misleads the user but does not actually produce inconsistent results.


x/tools/cmd/godoc: document as deprecated

Document this program as deprecated, and point users to golang.org/x/pkgsite/cmd/pkgsite.

I do not think that godoc should be deprecated. It serves a different purpose from pkgsite.
I use godoc as a local webserver for the documentation to my unpublished packages and as a reference for the go standard library. I do not want a local copy of the go.dev website. pkgsite also assumes you have a working internet connection, since all links but pkg-search connect to go.dev, while godoc is completely local. With pkgsite  I have to know what I am looking for, since there is no index of the packages in the standard lib. Also a local pkgsite seems to me to be quite unrealiable. After
go install golang.org/x/pkgsite/cmd/pksite@latest it claimed to be installed, but just does not work. The website comes up at port 8080, but all searches fail.
Hence I am wondering why a working program is supposed to be replaced by some much more unreliable and fragile piece of software that does not even cover the use cases of the orignal software. Also pkgsite has way too many dependieces which are not used at all in a local setup - this makes the software much more fragile and also increases its size by a factor of 4. I am wondering how this holds up to gos principle of simplicity.  godoc serves a simple purpose, pkgsite does not. I consider local use of pkgsite wrong and against the principles of go.


💅 Svelte : a component used as component AND type triggers the lint "All these imports are only used as types.biomelint/style/useImportType"

Environment information
bun
"@biomejs/biome": "^1.8.3",
6.5.0-10043-tuxedo x86_64 x86_64 x86_64 GNU/Linux

Reproduction

Create a Svelte component
Import it and use it both as type and as component
See lint

MyComponent.svelte

My component !

Case 1 : does not trigger the lint :
+page.svelte

<MyComponent />

Case 2 : triggers the lint :
+page.svelte

<MyComponent bind:this="{myComponent}" />

This 2nd syntax can be used to access component props & functions.
Rule name
types.biomelint/style/useImportType
Playground link
not needed
Expected result
No lint
Code of Conduct

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

This was also reported in a discussion: #3426. I will close the issue as a duplicate of #3426.


[Bug]-[300]:The binding is not displayed for the button group widget in the entity pane

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
The binding is not displayed for the button group widget in the entity pane

Steps To Reproduce

Go to canvas
Drag and drop the Button group widget In the entity pane
Click on the meat ball icon( 3 dots icon)
Click on Show Binding
There is no data displayed the pop up closed

Environment
Release
Version
Cloud

Stats

Stat
Values

Reach
300

Effort (months)
1

This has been solved now


[MB-2566] ADR about optimistic locking when updating children in an endpoint

Description
Currently in some endpoints like updateMTOShipment, we pass in the etag of the shipment and then update the address. However, this means we are not checking the etag of the address. And there’s only one spot in the header for If-Match.
This ADR decides in this case, it's best to create a separate endpoint for the child, so it can be properly updated with its own etag.
Slack convo: https://ustcdp3.slack.com/archives/CP6PTUPQF/p1592849994343000

Messages

:book:
:link: MB-2566

  Generated by :no_entry_sign: dangerJS against 7e5c97c8ffda441725478f336cf5837c24ee80c3


DataHandler doesnt use proper encoding after publishing a Webservice

Previously tracked via: https://bugs.openjdk.java.net/browse/JDK-7029376
FULL PRODUCT VERSION :
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Windows 2008 64Bit, Windows XP 64-Bit
A DESCRIPTION OF THE PROBLEM :
The DataHandler doesnt pay attention to the character-set after you publish a webservice via Endpoint.publish(..., ...).
The encoding is regarded when you dont publish a webservice.
I used a MimeBodyPart for testing but i could track the problem to the JDK-classes.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Please use the attached source-code. In order to compile you need mail.jar but the bug seems not to be related to this package.
run the code and take a look at system.out.
The umlauts are encoded in the same way in both lines despite different parameters for the encodign (utf-8 and iso-8859-1).
Uncomment the line with Endpoint.publish(..) and the line are encoded differently as they should be.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The encoding should be regarded. The umlauts should be encoded like:
=F6=E4=FCtest231
=C3=B6=C3=A4=C3=BCtest231
ACTUAL -
With the probided example the output looks like this:
=C3=B6=C3=A4=C3=BCtest231
=C3=B6=C3=A4=C3=BCtest231
or
=F6=E4=FCtest231
=F6=E4=FCtest231
depending on the file.encoding environment variable.
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
import java.io.OutputStream;
import javax.activation.DataHandler;
import javax.mail.internet.MimeBodyPart;
import javax.mail.internet.MimeUtility;
import javax.xml.ws.Endpoint;
import javax.jws.WebService;
@WebService(targetNamespace="http://www.mycompany.com/customerrelations", name="TestService")
public class enctest
{
public static void main(String[] args) throws Exception
{
enctest impl = new enctest();
Endpoint end = null;
//comment and uncomment the following line to see the difference
end = Endpoint.publish("http://localhost:81/Webservice", impl);
       MimeBodyPart mbptext = new MimeBodyPart();
       mbptext.setText("öäütest231", "iso-8859-1");
       mbptext.setHeader("Content-Type","text/plain; charset=\"iso-8859-1\"");

       DataHandler hdl = mbptext.getDataHandler();
       OutputStream os = MimeUtility.encode(System.out, "quoted-printable");
       //DataHandler->writeTo
       //--> ObjectDataContentHandler->writeTo
       //--> text_plain->writeTo
       hdl.writeTo(os);
       os.flush();

       System.out.println();

       MimeBodyPart mbptext2 = new MimeBodyPart();
       mbptext2.setText("öäütest231", "utf-8");
       mbptext2.setHeader("Content-Type","text/plain; charset=\"utf-8\"");

       DataHandler hdl2 = mbptext2.getDataHandler();
       OutputStream os2 = MimeUtility.encode(System.out, "quoted-printable");
       hdl2.writeTo(os2);
       os2.flush();

       if (end != null)
          end.stop();
}

public String doNothing()
{
    return "";
}

}
---------- END SOURCE ----------
Source: https://github.com/javaee/metro-jax-ws/issues/1230
Author: LanceAndersen

works as expected in v4


Ensure the ecs service has started

The ecs service sometimes fails to start, if docker fails to start on first try. This adds systemctl start ecs to the end of ec2 userdata, to force start it.

Updated 👍


Selected state in thje

I was trying to easily convey selected state with the show-labels set to false, and was surprised there was no easy way to get the selected state (without manually managing it which is a bit hacky).
So I modified the  .min.js version (using it in a vanilla html page) to add the isSelected: t.isSelected(e) to the options slot and i was able to do this in the slot
  <span class="checkbox-label" slot="option" slot-scope="scope">
      <input type="checkbox" :checked="scope.isSelected" @focus.prevent :key="scope.option.value"/>
      {{ scope.option.text }}
    </span>

And it seems to work perfectly, unless someone knows something I don't about performance.
I imagine it's the equivalent of this (as search slot param in the min.js references t.search so i assume isSelected would transfer like that)
 <slot name="option" :option="option" :search="search"  :isSelected="isSelected(option)" :index="index">

Also even a multipleShowCheck property that would automatically show the checkbox without even needing to use the slot would be awesome as well, and simple to add using the same kind of logic.

@TrendyTim Please provide repo link for your usecase.


Custom linting capability

Add lint checks for a subset of our repos to validate that

certain vars are present
restrict provider usage
restrict provisioner usage

If possible we should extend TFLint, otherwise this could be a new cli subcommand

validate that provider meta is set to expected


Show warning message in Jupyter notebooks

For unknown reason the previous implementation wouldn't
show a deprecation warning in Jupyter. The change introduced
here makes the warning to appear once in the same notebook.
N.B. in the appmode the warning is not shown.

For unknown reason the previous implementation wouldn't
show a deprecation warning in Jupyter. The change introduced
here makes the warning to appear once in the same notebook.

@yakutovicha Deprecation warnings are not shown by default.

This is a bit dangerous, since it may change the behavior of showing warnings unexpectedly for other users, however, since this is to be completely removed shortly, I think this is fine for a time-limited temporary solution.

I agree with @CasperWA that this appears to be a very blunt option. Are we sure that this is not going to lead to all deprecation warnings to be shown in completely unrelated contexts? Shouldn't we leave it up to the developers whether they want to see deprecation warnings as is standard practice?

This is a bit dangerous, since it may change the behavior of showing warnings unexpectedly for other users, however, since this is to be completely removed shortly, I think this is fine for a time-limited temporary solution.

I agree with @CasperWA that this appears to be a very blunt option. Are we sure that this is not going to lead to all deprecation warnings to be shown in completely unrelated contexts? Shouldn't we leave it up to the developers whether they want to see deprecation warnings as is standard practice?

That is how it should be, yes. And this will (as far as I know) show all DeprecationWarnings, unfortunately. But only once, of course.
In this case, however, I have chosen to accept this change for a short time, since it doesn't appear to show up in app mode and indeed also not in Voilà, but only when editing the notebook. Furthermore, it's a temporary implementation only relevant for this particular application. If we find a lot of users are complaining or asking questions about this we simply remove it and update immediately.
In the end, I think the deprecation warning on this is also a bit overkill, since I don't think a lot of users were using the application to begin with. And we should be able to update those use cases ourselves in most cases, either directly or indirectly.

@yakutovicha Deprecation warnings are not shown by default.

I am not sure what the role of the deprecation warnings then. I thought the deprecation warnings should warn the developers to change the code, but if they are not shown, what is the point?
AIso, the enabled warnings are only shown when the appmode is disabled. So we see them together with the code cells, which is again mostly for the developers.

In the end, I think the deprecation warning on this is also a bit overkill, since I don't think a lot of users were using the application to begin with. And we should be able to update those use cases ourselves in most cases, either directly or indirectly.

I believe the deprecation warnings are generally a good practice, so I would like to start using them wider. But if you think the way I did it is wrong, I would be happy to learn better practices.

@yakutovicha Deprecation warnings are not shown by default.

I am not sure what the role of the deprecation warnings then. I thought the deprecation warnings should warn the developers to change the code, but if they are not shown, what is the point?

Yes, when the developers opt-in to see them. However, enabling them by default has a lot of disadvantages which is why showing them by default was disabled with the release of Python 2.7 and 3.2. See the changelog for the motivation of this change and here for a discussion of this topic.

AIso, the enabled warnings are only shown when the appmode is disabled. So we see them together with the code cells, which is again mostly for the developers.

In the end, I think the deprecation warning on this is also a bit overkill, since I don't think a lot of users were using the application to begin with. And we should be able to update those use cases ourselves in most cases, either directly or indirectly.

I believe the deprecation warnings are generally a good practice, so I would like to start using them wider. But if you think the way I did it is wrong, I would be happy to learn better practices.

Using deprecation warnings requires the establishment of some basic policy with respect to support of deprecated features and the release of backwards incompatible changes. As long as that has been established they are good tool to prevent "surprises", otherwise they are rather pointless.

Yes, when the developers opt-in to see them. However, enabling them by default has a lot of disadvantages which is why showing them by default was disabled with the release of Python 2.7 and 3.2. See the changelog for the motivation of this change and here for a discussion of this topic.

So the motivation there is to reduce the noise produced by the warning messages. However, in AiiDAlab those warnings are additionally suppressed by the appmode, while for the developers it makes a lot of sense to see them. Therefore (as suggested by @csadorf, and I agree with that) - we might want to switch on those warnings globally.


Error on mobile but not desktop

I have a very simple request block that just renders some basic HTML:
url: https://mysite.com/page.php
res-type: md
render

This works fine on desktop Obsidian. In mobile, the blocks do not render and show this error:
Error: undefined is not an object (evaluating 'responseData.headers["content-type"].includes')
This same URL used to work fine in mobile, but something changed with an update. Is there some specific header the PHP script needs to output for this to work?

Have you try to run it without the res-type and/or without render?

Hello @nickian,
It seems that only these tags are allowed, although it is strange that it works on desktop but not on mobile.

It seems to be doing the same thing when I remove res-type and render.
I think I'm only using tags on that whitelist. I have a script that makes a request to Coin Market Cap to get crypto prices and it just outputs this:
echo '
';
echo '  ';
echo 'BTC: $'.number_format(round($response['data'][1]['quote']['USD']['price'], 2), 2). ' ('.round($response['data'][1]['quote']['USD']['percent_change_24h'], 2).'% in last 24h)';
echo '
';

echo '
';
echo '  ';
echo 'ETH: $'.number_format(round($response['data'][1027]['quote']['USD']['price'], 2), 2). ' ('.round($response['data'][1027]['quote']['USD']['percent_change_24h'], 2).'% in last 24h)
';
echo '
';

echo '
';
echo '  ';
echo 'DOGE: $'.number_format(round($response['data'][74]['quote']['USD']['price'], 2), 2). ' ('.round($response['data'][74]['quote']['USD']['percent_change_24h'], 2).'% in last 24h)
';
echo '
';

echo '
';
echo '  ';
echo 'SHIB: $'.number_format($response['data'][5994]['quote']['USD']['price'], 8, '.', ''). ' ('.round($response['data'][5994]['quote']['USD']['percent_change_24h'], 2).'% in last 24h)';
echo '
';

Inside a <?php> tag?

I'm thinking of adding a way to turn HTML sanitizing on and off, what do you think?

I think that would be good. I'm still having the issue. But now it says Error: JSON Parse error: Unrecognized token '<'


fix: use chain for TransformableStream to fail if TransformationException

Issue
https://github.com/gravitee-io/issues/issues/7130

Gravitee.io Automatic Deployment
🚀 A prerelease version of this package has been published on Gravitee's private artifactory, you can:

use it directly by updating your project with version: 1.0.1-SNAPSHOT.issues-7130-transformationexception-chain
download it from Artifactory here

:tada: This PR is included in version 1.0.1 :tada:
The release is available on:

1.0.1
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.1 :tada:
The release is available on:

1.0.1
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.1 :tada:
The release is available on:

1.0.1
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.1.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket: