[REQ]  Solar radiation: use weatherstation sensor

As it appears looking at v0.50 calculations use solar radiation aswell, which is estimated using sun hours or temperatures. As weatherstatons also provide UV / Radiation sensors; i would like to opt for adding a radiation sensor option when using actual sensors.

This will make the precipitation calculation even more acurate.

That's fair. By the way, why are you using this component anyway? Your image shows that you already have the ET value... So all the calculations could be skipped...

Because i didn't know :-). Also the automatic bucket isn't part of the weatherstation, so skipping a day isn't possible..

right, ok, I get that. I will see if I can make the requested change and maybe even just use the ET value provided by the weather station. Out of curiosity, could you track the calculations and the ET value reported by the weather station to see if they compare?

yes. will do. At this moment hourly ET value: 5.454794381670322, ET of weatherstation: 5.207 so that looks comparable...

BTW here you can find info of how the Davis system is calculating ET: https://www.davisinstruments.com/product_documents/weather/app_notes/AN_28-derived-weather-variables.pdf
It's a lot of acabadabra to me:-)

I saw the ET value of the Davis station resets to 0 at 12AM. Right now the ET value of davis = 1.803; on hourly sensors 5.888761835879981. So i guess the Davis ET value will be daily based, i will compare daily value tonight at 23h

you can now use a sensor for solar radiation or even skip all calculations and just provide a sensor for ET. Please test.

I don't know why but HASmartirrigation component is not showing v0.0.55 as new version. It still lists v0.0.50b as latest..

No, I choose pre-release on purpose as I had no good way testing this end to end. Enable the install of beta versions in HACS or just download and overwrite the files manually, please. Again, I am depending on you to test this.

Ah ok. I copied over the new version. 1st issue (i think): when selecting an ET sensor, i shouldn't have to insert reference values for each month? I get this wizard step after inserting the ET sensor..

After adding both integrations to HA:
2020-06-25 16:11:18 WARNING (MainThread) [custom_components.smart_irrigation] sources: {'use_owm_precipitation': True, 'use_owm_temperature': True, 'use_owm_min_temperature': True, 'use_owm_max_temperature': True, 'use_owm_dewpoint': True, 'use_owm_pressure': True, 'use_owm_humidity': True, 'use_owm_windspeed': True, 'calculate_solar_radiation': True, 'calculate_ET_value': False}
2020-06-25 16:11:18 WARNING (MainThread) [custom_components.smart_irrigation] sensors: {'sensor_et': 'sensor.davis_verdamping'}
2020-06-25 16:12:03 ERROR (MainThread) [frontend.js.latest.202006033] http://homeassistant:8123/hacsfiles/circle-sensor-card/circle-sensor-card.js:76:79 Uncaught TypeError: Cannot read property 'state' of undefined
2020-06-25 16:14:49 WARNING (MainThread) [custom_components.smart_irrigation] sources: {'use_owm_precipitation': False, 'use_owm_temperature': False, 'use_owm_min_temperature': False, 'use_owm_max_temperature': False, 'use_owm_dewpoint': False, 'use_owm_pressure': False, 'use_owm_humidity': False, 'use_owm_windspeed': False}
2020-06-25 16:14:49 WARNING (MainThread) [custom_components.smart_irrigation] sensors: {'sensor_precipitation': 'sensor.davis_regenhoveelheid_dag', 'sensor_temperature': 'sensor.davis_buitentemperatuur', 'sensor_min_temperature': 'sensor.davis_laagste_temperatuur', 'sensor_max_temperature': 'sensor.davis_hoogste_temperatuur', 'sensor_dewpoint': 'sensor.davis_dauwpunt', 'sensor_pressure': 'sensor.davis_barometer', 'sensor_humidity': 'sensor.davis_luchtvochtigheid', 'sensor_windspeed': 'sensor.davis_windsnelheid_gemiddeld', 'sensor_solar_radiation': 'sensor.davis_zonnestraling'}
sensor values voortuin (running ET sensor:

sensor values achtertuin (running all weatherstation sensors):

Hmm, I think you're right, reference ETs should not be required when setting the ET sensor . Or maybe it is.  I have to think about that. Thanks. I see no other obvious issues, correct? Please let it run and see if the calculations make sense. Many thanks again

will look at the values tonight at 23:55. I set this right before ET sensor is reset to 0.
Keep you posted.

Additional info: after adding the ET value as sensor to HA it behaves as calculated ET:

Looks good!

I have looked into it, you still need to provide the reference ET values since we need a way to calculate the base schedule index, which is based on the max(reference_et). base schedule index is used for water budget and adjusted run time. So I think this is correct.

Jeroen,
Hourly value at 23:50 tonight:

These values are comparable.
Daily sensors after 23:55 (time which daily value is calculated:

the voortuin is using ET sensor, so expected to see same ET vvalue as realtime weatherstation value:

Hmm strang thing i see:

Hourly adjusted runtime on achtertuin is not updating? Last updated 7 hours ago.
Using ET sensor is updating fine, beck to 0 at 0:00 which is expected:

Hmm, that is weird, did you see anything in the logs that points to why this update did not happen?

Nope no logged messages.. let’s see what the values have done in the morning..

Can you enable info level logging for this component? It will log a lot of info, so be prepared, but might help to explain what is going on.

Hmm then i will add it to my dev HASS. How to manually install the integration? I added the smartirrigation folder to custom_components but i cannot select it from integration setup..

Found it, browser cache. Here is the log:
2020-06-26 11:12:30 WARNING (MainThread) [homeassistant.loader] You are using a custom integration for smart_irrigation which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant.
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation]
Smart Irrigation
Version: 0.0.55
If you have any issues with this you need to open an issue here:
https://github.com/jeroenterheerdt/HASmartIrrigation/issues
2020-06-26 11:12:31 WARNING (MainThread) [custom_components.smart_irrigation] sources: {'use_owm_dewpoint': False, 'use_owm_humidity': False, 'use_owm_max_temperature': False, 'use_owm_min_temperature': False, 'use_owm_precipitation': False, 'use_owm_pressure': False, 'use_owm_temperature': False, 'use_owm_windspeed': False}
2020-06-26 11:12:31 WARNING (MainThread) [custom_components.smart_irrigation] sensors: {'sensor_dewpoint': 'sensor.davis_dauwpunt', 'sensor_humidity': 'sensor.davis_luchtvochtigheid', 'sensor_max_temperature': 'sensor.davis_hoogste_temperatuur', 'sensor_min_temperature': 'sensor.davis_laagste_temperatuur', 'sensor_precipitation': 'sensor.davis_regenhoveelheid_dag', 'sensor_pressure': 'sensor.davis_barometer', 'sensor_solar_radiation': 'sensor.davis_zonnestraling', 'sensor_temperature': 'sensor.davis_buitentemperatuur', 'sensor_windspeed': 'sensor.davis_windsnelheid_gemiddeld'}
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation] Auto refresh is enabled. Scheduling for 23:55.
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation] Initial update scheduled for 2020-06-26 11:17:31.664927+02:00
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation] Updating Smart Irrigation Data
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] sensor init for current_adjusted_run_time. bucket_delta=0
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] sensor init for adjusted_run_time. bucket=0
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation] registering: type: Base Schedule Index, entity: sensor.smart_irrigation_base_schedule_index
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] async_added_t_hass type: Base Schedule Index state: 686.0, attributes: {'area': '26.0 m2', 'auto_refresh': True, 'auto_refresh_time': '23:55', 'base_schedule_index_minutes': '11.43 min', 'coastal': False, 'estimate_solrad_from_temp': True, 'flow': '7.845 l', 'friendly_name': 'Base Schedule Index', 'icon': 'mdi:sprinkler', 'initial_update_delay': '300 s', 'number_of_sprinklers': 1.0, 'peak_evapotranspiration': '3.45 mm', 'precipitation_rate': '18.103846153846153 mm/hour', 'reference_evapotranspiration': '[0.46, 0.73, 1.29, 2.09, 3.01, 3.29, 3.45, 3.02, 1.87, 1.1, 0.57, 0.42] mm', 'throughput': '7.845 liter/minute', 'unit_of_measurement': 's'}
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state for type: Base Schedule Index
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state for type: Base Schedule Index
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation] registering: type: Hourly Adjusted Run Time, entity: sensor.smart_irrigation_hourly_adjusted_run_time
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] async_added_t_hass type: Hourly Adjusted Run Time state: 0, attributes: {'adjusted_run_time_minutes': '0.0 min', 'evapotranspiration': '0.0 mm', 'friendly_name': 'Hourly Adjusted Run Time', 'icon': 'mdi:sprinkler', 'netto_precipitation': '0.0 mm', 'precipitation': '0.0 mm', 'rain': '0.0 mm', 'snow': '0.0 mm', 'unit_of_measurement': 's', 'water_budget': '0.0 %'}
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] async_added_t_hass type: Hourly Adjusted Run Time, attribute: evapotranspiration, attribute_value: 0.0 mm, numeric_part: 0.0, show_units: True, a_val was str or contained ' ': True
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] async_added_t_hass type: Hourly Adjusted Run Time, attribute: netto_precipitation, attribute_value: 0.0 mm, numeric_part: 0.0, show_units: True, a_val was str or contained ' ': True
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] async_added_to_hass restoring state, setting netto precipitation / bucket_delta to: 0.0
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] async_added_t_hass type: Hourly Adjusted Run Time, attribute: precipitation, attribute_value: 0.0 mm, numeric_part: 0.0, show_units: True, a_val was str or contained ' ': True
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] async_added_t_hass type: Hourly Adjusted Run Time, attribute: rain, attribute_value: 0.0 mm, numeric_part: 0.0, show_units: True, a_val was str or contained ' ': True
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] async_added_t_hass type: Hourly Adjusted Run Time, attribute: snow, attribute_value: 0.0 mm, numeric_part: 0.0, show_units: True, a_val was str or contained ' ': True
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] async_added_t_hass type: Hourly Adjusted Run Time, attribute: water_budget, attribute_value: 0.0 %, numeric_part: 0.0, show_units: True, a_val was str or contained ' ': True
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] async_added_t_hass type: Hourly Adjusted Run Time, attribute: adjusted_run_time_minutes, attribute_value: 0.0 min, numeric_part: 0.0, show_units: True, a_val was str or contained ' ': True
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state for type: Hourly Adjusted Run Time
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_dewpoint, sensor_setting: sensor_dewpoint, sensor_name: sensor.davis_dauwpunt, sensor_state: None
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_humidity, sensor_setting: sensor_humidity, sensor_name: sensor.davis_luchtvochtigheid, sensor_state: None
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_max_temperature, sensor_setting: sensor_max_temperature, sensor_name: sensor.davis_hoogste_temperatuur, sensor_state: None
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_min_temperature, sensor_setting: sensor_min_temperature, sensor_name: sensor.davis_laagste_temperatuur, sensor_state: None
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_precipitation, sensor_setting: sensor_precipitation, sensor_name: sensor.davis_regenhoveelheid_dag, sensor_state: None
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_pressure, sensor_setting: sensor_pressure, sensor_name: sensor.davis_barometer, sensor_state: None
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_temperature, sensor_setting: sensor_temperature, sensor_name: sensor.davis_buitentemperatuur, sensor_state: None
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_windspeed, sensor_setting: sensor_windspeed, sensor_name: sensor.davis_windsnelheid_gemiddeld, sensor_state: None
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] rain: 0.0, snow: 0.0
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] skipped calculating evapotranspiration, got the following value from a sensor: 0.0
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] Calculated water_budget = 0 and adjusted_run_time: 0 for type: Hourly Adjusted Run Time. Bucket value was: 0.0, and base schedule index is:<PHONE_NUMBER>095604, force mode is: False, force mode duration is: 0, lead_time is: 0, maximum_duration: 9000, change percentage: 1.0, type: Hourly Adjusted Run Time
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state: just updated hourly_bucket_list: [0.0]
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state for type: Hourly Adjusted Run Time
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_dewpoint, sensor_setting: sensor_dewpoint, sensor_name: sensor.davis_dauwpunt, sensor_state: None
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_humidity, sensor_setting: sensor_humidity, sensor_name: sensor.davis_luchtvochtigheid, sensor_state: None
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_max_temperature, sensor_setting: sensor_max_temperature, sensor_name: sensor.davis_hoogste_temperatuur, sensor_state: None
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_min_temperature, sensor_setting: sensor_min_temperature, sensor_name: sensor.davis_laagste_temperatuur, sensor_state: None
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_precipitation, sensor_setting: sensor_precipitation, sensor_name: sensor.davis_regenhoveelheid_dag, sensor_state: None
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_pressure, sensor_setting: sensor_pressure, sensor_name: sensor.davis_barometer, sensor_state: None
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_temperature, sensor_setting: sensor_temperature, sensor_name: sensor.davis_buitentemperatuur, sensor_state: None
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_windspeed, sensor_setting: sensor_windspeed, sensor_name: sensor.davis_windsnelheid_gemiddeld, sensor_state: None
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] rain: 0, snow: 0
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] skipped calculating evapotranspiration, got the following value from a sensor: 0.0
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] Calculated water_budget = 0 and adjusted_run_time: 0 for type: Hourly Adjusted Run Time. Bucket value was: 0.0, and base schedule index is:<PHONE_NUMBER>095604, force mode is: False, force mode duration is: 0, lead_time is: 0, maximum_duration: 9000, change percentage: 1.0, type: Hourly Adjusted Run Time
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state: just updated hourly_bucket_list: [0.0, 0.0]
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation] registering: type: Daily Adjusted Run Time, entity: sensor.smart_irrigation_daily_adjusted_run_time
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] async_added_t_hass type: Daily Adjusted Run Time state: 0, attributes: {'adjusted_run_time_minutes': '0.0 min', 'bucket': '0.0 mm', 'force_mode_duration': 0, 'force_mode_enabled': False, 'friendly_name': 'Daily Adjusted Run Time', 'icon': 'mdi:sprinkler', 'lead_time': '0 s', 'maximum_duration': '9000 s', 'unit_of_measurement': 's', 'water_budget': '0.0 %'}
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] async_added_t_hass type: Daily Adjusted Run Time, attribute: water_budget, attribute_value: 0.0 %, numeric_part: 0.0, show_units: True, a_val was str or contained ' ': True
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] async_added_t_hass type: Daily Adjusted Run Time, attribute: bucket, attribute_value: 0.0 mm, numeric_part: 0.0, show_units: True, a_val was str or contained ' ': True
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] async_added_to_hass restoring state, settting bucket to: 0.0
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] async_added_t_hass type: Daily Adjusted Run Time, attribute: adjusted_run_time_minutes, attribute_value: 0.0 min, numeric_part: 0.0, show_units: True, a_val was str or contained ' ': True
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state for type: Daily Adjusted Run Time
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] Calculated water_budget = 0 and adjusted_run_time: 0 for type: Daily Adjusted Run Time. Bucket value was: 0.0, and base schedule index is:<PHONE_NUMBER>095604, force mode is: False, force mode duration is: 0, lead_time is: 0, maximum_duration: 9000, change percentage: 1.0, type: Daily Adjusted Run Time
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] calculating wb and art for daily adjusted run time, result: {'wb': 0, 'art': 0}
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state for type: Daily Adjusted Run Time
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] Calculated water_budget = 0 and adjusted_run_time: 0 for type: Daily Adjusted Run Time. Bucket value was: 0.0, and base schedule index is:<PHONE_NUMBER>095604, force mode is: False, force mode duration is: 0, lead_time is: 0, maximum_duration: 9000, change percentage: 1.0, type: Daily Adjusted Run Time
2020-06-26 11:12:31 INFO (MainThread) [custom_components.smart_irrigation.sensor] calculating wb and art for daily adjusted run time, result: {'wb': 0, 'art': 0}
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation] Initial update triggered - calling calculate hourly adjusted run time now.
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation] Calculate Hourly Adjusted Run Time service called, calculating now.
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation] Updating Smart Irrigation Data
2020-06-26 11:17:32 INFO (SyncWorker_2) [custom_components.smart_irrigation.sensor] _hourly_data_updated, calling update_state for type Hourly Adjusted Run Time
2020-06-26 11:17:32 INFO (SyncWorker_2) [custom_components.smart_irrigation.sensor] update_state for type: Hourly Adjusted Run Time
2020-06-26 11:17:32 INFO (SyncWorker_2) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_dewpoint, sensor_setting: sensor_dewpoint, sensor_name: sensor.davis_dauwpunt, sensor_state: <state sensor.davis_dauwpunt=16.8; unit_of_measurement=°C, friendly_name=Davis Dauwpunt, icon=mdi:thermometer @ 2020-06-26T11:16:56.233600+02:00>
2020-06-26 11:17:32 INFO (SyncWorker_2) [custom_components.smart_irrigation.sensor] update_state state value: 16.8
2020-06-26 11:17:32 INFO (SyncWorker_2) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_humidity, sensor_setting: sensor_humidity, sensor_name: sensor.davis_luchtvochtigheid, sensor_state: <state sensor.davis_luchtvochtigheid=52; unit_of_measurement=%, friendly_name=Davis Luchtvochtigheid, icon=mdi:water-percent @ 2020-06-26T11:12:37.587615+02:00>
2020-06-26 11:17:32 INFO (SyncWorker_2) [custom_components.smart_irrigation.sensor] update_state state value: 52
2020-06-26 11:17:32 INFO (SyncWorker_2) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_max_temperature, sensor_setting: sensor_max_temperature, sensor_name: sensor.davis_hoogste_temperatuur, sensor_state: <state sensor.davis_hoogste_temperatuur=27.8; unit_of_measurement=°C, friendly_name=Davis Hoogste Temperatuur, icon=mdi:weather-windy @ 2020-06-26T11:12:37.628639+02:00>
2020-06-26 11:17:32 INFO (SyncWorker_2) [custom_components.smart_irrigation.sensor] update_state state value: 27.8
2020-06-26 11:17:32 INFO (SyncWorker_2) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_min_temperature, sensor_setting: sensor_min_temperature, sensor_name: sensor.davis_laagste_temperatuur, sensor_state: <state sensor.davis_laagste_temperatuur=18.3; unit_of_measurement=°C, friendly_name=Davis Laagste Temperatuur, icon=mdi:weather-windy @ 2020-06-26T11:12:37.629338+02:00>
2020-06-26 11:17:32 INFO (SyncWorker_2) [custom_components.smart_irrigation.sensor] update_state state value: 18.3
2020-06-26 11:17:32 INFO (SyncWorker_2) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_precipitation, sensor_setting: sensor_precipitation, sensor_name: sensor.davis_regenhoveelheid_dag, sensor_state: <state sensor.davis_regenhoveelheid_dag=0.0; unit_of_measurement=mm, friendly_name=Davis Regenhoveelheid Dag, icon=mdi:weather-rainy @ 2020-06-26T11:12:37.588388+02:00>
2020-06-26 11:17:32 INFO (SyncWorker_2) [custom_components.smart_irrigation.sensor] update_state state value: 0.0
2020-06-26 11:17:32 INFO (SyncWorker_2) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_pressure, sensor_setting: sensor_pressure, sensor_name: sensor.davis_barometer, sensor_state: <state sensor.davis_barometer=1011.0; unit_of_measurement=mbar, friendly_name=Davis Barometer, icon=mdi:gauge @ 2020-06-26T11:17:06.251640+02:00>
2020-06-26 11:17:32 INFO (SyncWorker_2) [custom_components.smart_irrigation.sensor] update_state state value: 1011.0
2020-06-26 11:17:32 INFO (SyncWorker_2) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_temperature, sensor_setting: sensor_temperature, sensor_name: sensor.davis_buitentemperatuur, sensor_state: <state sensor.davis_buitentemperatuur=27.6; unit_of_measurement=°C, friendly_name=Davis Buitentemperatuur, icon=mdi:thermometer @ 2020-06-26T11:17:26.276583+02:00>
2020-06-26 11:17:32 INFO (SyncWorker_2) [custom_components.smart_irrigation.sensor] update_state state value: 27.6
2020-06-26 11:17:32 INFO (SyncWorker_2) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_windspeed, sensor_setting: sensor_windspeed, sensor_name: sensor.davis_windsnelheid_gemiddeld, sensor_state: <state sensor.davis_windsnelheid_gemiddeld=4; unit_of_measurement=km/h, friendly_name=Davis Windsnelheid Gemiddeld, icon=mdi:weather-windy @ 2020-06-26T11:16:56.233385+02:00>
2020-06-26 11:17:32 INFO (SyncWorker_2) [custom_components.smart_irrigation.sensor] update_state state value: 4
2020-06-26 11:17:32 INFO (SyncWorker_2) [custom_components.smart_irrigation.sensor] rain: 0.0, snow: 0.0
2020-06-26 11:17:32 INFO (SyncWorker_2) [custom_components.smart_irrigation.sensor] skipped calculating evapotranspiration, got the following value from a sensor: 0.0
2020-06-26 11:17:32 INFO (SyncWorker_2) [custom_components.smart_irrigation.sensor] Calculated water_budget = 0 and adjusted_run_time: 0 for type: Hourly Adjusted Run Time. Bucket value was: 0.0, and base schedule index is:<PHONE_NUMBER>095604, force mode is: False, force mode duration is: 0, lead_time is: 0, maximum_duration: 9000, change percentage: 1.0, type: Hourly Adjusted Run Time
2020-06-26 11:17:32 INFO (SyncWorker_2) [custom_components.smart_irrigation.sensor] update_state: just updated hourly_bucket_list: [0.0, 0.0, 0.0]
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state for type: Hourly Adjusted Run Time
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_dewpoint, sensor_setting: sensor_dewpoint, sensor_name: sensor.davis_dauwpunt, sensor_state: <state sensor.davis_dauwpunt=16.8; unit_of_measurement=°C, friendly_name=Davis Dauwpunt, icon=mdi:thermometer @ 2020-06-26T11:16:56.233600+02:00>
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state state value: 16.8
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_humidity, sensor_setting: sensor_humidity, sensor_name: sensor.davis_luchtvochtigheid, sensor_state: <state sensor.davis_luchtvochtigheid=52; unit_of_measurement=%, friendly_name=Davis Luchtvochtigheid, icon=mdi:water-percent @ 2020-06-26T11:12:37.587615+02:00>
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state state value: 52
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_max_temperature, sensor_setting: sensor_max_temperature, sensor_name: sensor.davis_hoogste_temperatuur, sensor_state: <state sensor.davis_hoogste_temperatuur=27.8; unit_of_measurement=°C, friendly_name=Davis Hoogste Temperatuur, icon=mdi:weather-windy @ 2020-06-26T11:12:37.628639+02:00>
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state state value: 27.8
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_min_temperature, sensor_setting: sensor_min_temperature, sensor_name: sensor.davis_laagste_temperatuur, sensor_state: <state sensor.davis_laagste_temperatuur=18.3; unit_of_measurement=°C, friendly_name=Davis Laagste Temperatuur, icon=mdi:weather-windy @ 2020-06-26T11:12:37.629338+02:00>
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state state value: 18.3
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_precipitation, sensor_setting: sensor_precipitation, sensor_name: sensor.davis_regenhoveelheid_dag, sensor_state: <state sensor.davis_regenhoveelheid_dag=0.0; unit_of_measurement=mm, friendly_name=Davis Regenhoveelheid Dag, icon=mdi:weather-rainy @ 2020-06-26T11:12:37.588388+02:00>
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state state value: 0.0
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_pressure, sensor_setting: sensor_pressure, sensor_name: sensor.davis_barometer, sensor_state: <state sensor.davis_barometer=1011.0; unit_of_measurement=mbar, friendly_name=Davis Barometer, icon=mdi:gauge @ 2020-06-26T11:17:06.251640+02:00>
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state state value: 1011.0
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_temperature, sensor_setting: sensor_temperature, sensor_name: sensor.davis_buitentemperatuur, sensor_state: <state sensor.davis_buitentemperatuur=27.6; unit_of_measurement=°C, friendly_name=Davis Buitentemperatuur, icon=mdi:thermometer @ 2020-06-26T11:17:26.276583+02:00>
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state state value: 27.6
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_windspeed, sensor_setting: sensor_windspeed, sensor_name: sensor.davis_windsnelheid_gemiddeld, sensor_state: <state sensor.davis_windsnelheid_gemiddeld=4; unit_of_measurement=km/h, friendly_name=Davis Windsnelheid Gemiddeld, icon=mdi:weather-windy @ 2020-06-26T11:16:56.233385+02:00>
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state state value: 4
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] rain: 0.0, snow: 0.0
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] skipped calculating evapotranspiration, got the following value from a sensor: 0.0
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] Calculated water_budget = 0 and adjusted_run_time: 0 for type: Hourly Adjusted Run Time. Bucket value was: 0.0, and base schedule index is:<PHONE_NUMBER>095604, force mode is: False, force mode duration is: 0, lead_time is: 0, maximum_duration: 9000, change percentage: 1.0, type: Hourly Adjusted Run Time
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state: just updated hourly_bucket_list: [0.0, 0.0, 0.0, 0.0]
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state for type: Hourly Adjusted Run Time
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_dewpoint, sensor_setting: sensor_dewpoint, sensor_name: sensor.davis_dauwpunt, sensor_state: <state sensor.davis_dauwpunt=16.8; unit_of_measurement=°C, friendly_name=Davis Dauwpunt, icon=mdi:thermometer @ 2020-06-26T11:16:56.233600+02:00>
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state state value: 16.8
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_humidity, sensor_setting: sensor_humidity, sensor_name: sensor.davis_luchtvochtigheid, sensor_state: <state sensor.davis_luchtvochtigheid=52; unit_of_measurement=%, friendly_name=Davis Luchtvochtigheid, icon=mdi:water-percent @ 2020-06-26T11:12:37.587615+02:00>
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state state value: 52
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_max_temperature, sensor_setting: sensor_max_temperature, sensor_name: sensor.davis_hoogste_temperatuur, sensor_state: <state sensor.davis_hoogste_temperatuur=27.8; unit_of_measurement=°C, friendly_name=Davis Hoogste Temperatuur, icon=mdi:weather-windy @ 2020-06-26T11:12:37.628639+02:00>
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state state value: 27.8
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_min_temperature, sensor_setting: sensor_min_temperature, sensor_name: sensor.davis_laagste_temperatuur, sensor_state: <state sensor.davis_laagste_temperatuur=18.3; unit_of_measurement=°C, friendly_name=Davis Laagste Temperatuur, icon=mdi:weather-windy @ 2020-06-26T11:12:37.629338+02:00>
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state state value: 18.3
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_precipitation, sensor_setting: sensor_precipitation, sensor_name: sensor.davis_regenhoveelheid_dag, sensor_state: <state sensor.davis_regenhoveelheid_dag=0.0; unit_of_measurement=mm, friendly_name=Davis Regenhoveelheid Dag, icon=mdi:weather-rainy @ 2020-06-26T11:12:37.588388+02:00>
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state state value: 0.0
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_pressure, sensor_setting: sensor_pressure, sensor_name: sensor.davis_barometer, sensor_state: <state sensor.davis_barometer=1011.0; unit_of_measurement=mbar, friendly_name=Davis Barometer, icon=mdi:gauge @ 2020-06-26T11:17:06.251640+02:00>
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state state value: 1011.0
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_temperature, sensor_setting: sensor_temperature, sensor_name: sensor.davis_buitentemperatuur, sensor_state: <state sensor.davis_buitentemperatuur=27.6; unit_of_measurement=°C, friendly_name=Davis Buitentemperatuur, icon=mdi:thermometer @ 2020-06-26T11:17:26.276583+02:00>
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state state value: 27.6
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for type: Hourly Adjusted Run Time, source: use_owm_windspeed, sensor_setting: sensor_windspeed, sensor_name: sensor.davis_windsnelheid_gemiddeld, sensor_state: <state sensor.davis_windsnelheid_gemiddeld=4; unit_of_measurement=km/h, friendly_name=Davis Windsnelheid Gemiddeld, icon=mdi:weather-windy @ 2020-06-26T11:16:56.233385+02:00>
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state state value: 4
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] rain: 0.0, snow: 0.0
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] skipped calculating evapotranspiration, got the following value from a sensor: 0.0
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] Calculated water_budget = 0 and adjusted_run_time: 0 for type: Hourly Adjusted Run Time. Bucket value was: 0.0, and base schedule index is:<PHONE_NUMBER>095604, force mode is: False, force mode duration is: 0, lead_time is: 0, maximum_duration: 9000, change percentage: 1.0, type: Hourly Adjusted Run Time
2020-06-26 11:17:32 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state: just updated hourly_bucket_list: [0.0, 0.0, 0.0, 0.0, 0.0]
So it isn't calculating as it is missing the radiation sensor. The name of the radiation sensor: sensor.davis_zonnestraling i added it correctly during setup..

i think the check to see it ET sensor is used is not correct:
skipped calculating evapotranspiration, got the following value from a sensor: 0.0

@posixx - the logs  you shared - is this for a component that is supposed to do the calculation of ET? Did you enable or disable calculation of ET in the first screen when you set up the component?

Yes this is without ET sensor, so first wizardstep i kept the checkbox selected. After that i unselected all OWM sensors and used my own.

hmm..more debugging to do then ;)

No hurry; I’m using ET sensor on my production system and that is working great..

OK, so the scenario where to use a ET sensor works fine? Awesome, that is good news. Its interesting that it would skip calculations in the scenario with just a solar radiation sensor.

Yes using ET sensor works great. Hourly sensor values:

And daily calculated based on that:

I only use ET sersors right now so if calculations are correct i don't know, my dev system is not runnign 24/7,,

Hi @posixx a new beta release is ready: 0.0.56 - please test it. I found a bug with the solar radiation, it should work now.

Ok as you can see i have configured solar sensor as it is mentioned at startup:
2020-07-01 10:16:08 INFO (MainThread) [custom_components.smart_irrigation] Smart Irrigation sources: {'use_owm_dewpoint': False, 'use_owm_humidity': False, 'use_owm_max_temperature': False, 'use_owm_min_temperature': False, 'use_owm_precipitation': False, 'use_owm_pressure': False, 'use_owm_temperature': False, 'use_owm_windspeed': False}
2020-07-01 10:16:08 INFO (MainThread) [custom_components.smart_irrigation] Smart Irrigation sensors: {'sensor_dewpoint': 'sensor.davis_dauwpunt', 'sensor_humidity': 'sensor.davis_luchtvochtigheid', 'sensor_max_temperature': 'sensor.davis_hoogste_temperatuur', 'sensor_min_temperature': 'sensor.davis_laagste_temperatuur', 'sensor_precipitation': 'sensor.davis_regenhoveelheid_dag', 'sensor_pressure': 'sensor.davis_barometer', 'sensor_solar_radiation': 'sensor.davis_zonnestraling', 'sensor_temperature': 'sensor.davis_buitentemperatuur', 'sensor_windspeed': 'sensor.davis_windsnelheid_gemiddeld'}
But i still get:
[custom_components.smart_irrigation.sensor] skipped calculating evapotranspiration, got the following value from a sensor: 0.0
None of the sensors i configured have a value of zero during this calculation, i double-checked. So the only issue which i can think of; youj check for a value for the evaporation sensor even when we have configured to not use that. Ofcourse that sensor value is zero / empty as it isn't configured.

Hmpf, that is weird. OK, I'll look at it again.

'sensor_solar_radiation': 'sensor.davis_zonnestraling' what do you mean it's not there?

It is in the sensors list yes, but no in the sources list. That sources list is passed from the setup and used to figure out which sensors might have been configured. I can try to refractor it now that I think of it. Regardless, I am seeing a flag for solar radiation in the sources list and you are not seeing it.

I removed the integration and readded:
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] Calculated water_budget = 0 and adjusted_run_time: 0 for type: Hourly Adjusted Run Time. Bucket value was: 7.1484155556123525, and base schedule index is:<PHONE_NUMBER>095604, force mode is: False, force mode duration is: 0, lead_time is: 0, maximum_duration: -1, change percentage: 1.0, type: Hourly Adjusted Run Time
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state: just updated hourly_bucket_list: [7.1484155556123525]
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state for type: Hourly Adjusted Run Time
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for instance Smart_Irrigation, type: Hourly Adjusted Run Time, source: use_owm_precipitation, sensor_setting: sensor_precipitation, sensor_name: sensor.davis_regenhoveelheid_dag, sensor_state: <state sensor.davis_regenhoveelheid_dag=12.4; unit_of_measurement=mm, friendly_name=Davis Regenhoveelheid Dag, icon=mdi:weather-rainy @ 2020-07-01T17:41:39.626108+02:00>
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state state value: 12.4
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for instance Smart_Irrigation, type: Hourly Adjusted Run Time, source: use_owm_temperature, sensor_setting: sensor_temperature, sensor_name: sensor.davis_buitentemperatuur, sensor_state: <state sensor.davis_buitentemperatuur=21.3; unit_of_measurement=°C, friendly_name=Davis Buitentemperatuur, icon=mdi:thermometer @ 2020-07-01T17:55:39.679069+02:00>
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state state value: 21.3
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for instance Smart_Irrigation, type: Hourly Adjusted Run Time, source: use_owm_min_temperature, sensor_setting: sensor_min_temperature, sensor_name: sensor.davis_laagste_temperatuur, sensor_state: <state sensor.davis_laagste_temperatuur=16.7; unit_of_measurement=°C, friendly_name=Davis Laagste Temperatuur, icon=mdi:weather-windy @ 2020-07-01T10:19:01.054497+02:00>
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state state value: 16.7
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for instance Smart_Irrigation, type: Hourly Adjusted Run Time, source: use_owm_max_temperature, sensor_setting: sensor_max_temperature, sensor_name: sensor.davis_hoogste_temperatuur, sensor_state: <state sensor.davis_hoogste_temperatuur=21.6; unit_of_measurement=°C, friendly_name=Davis Hoogste Temperatuur, icon=mdi:weather-windy @ 2020-07-01T17:38:01.235000+02:00>
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state state value: 21.6
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for instance Smart_Irrigation, type: Hourly Adjusted Run Time, source: use_owm_dewpoint, sensor_setting: sensor_dewpoint, sensor_name: sensor.davis_dauwpunt, sensor_state: <state sensor.davis_dauwpunt=16.4; unit_of_measurement=°C, friendly_name=Davis Dauwpunt, icon=mdi:thermometer @ 2020-07-01T17:55:39.680206+02:00>
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state state value: 16.4
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for instance Smart_Irrigation, type: Hourly Adjusted Run Time, source: use_owm_pressure, sensor_setting: sensor_pressure, sensor_name: sensor.davis_barometer, sensor_state: <state sensor.davis_barometer=1006.3; unit_of_measurement=mbar, friendly_name=Davis Barometer, icon=mdi:gauge @ 2020-07-01T17:55:09.595408+02:00>
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state state value: 1006.3
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for instance Smart_Irrigation, type: Hourly Adjusted Run Time, source: use_owm_humidity, sensor_setting: sensor_humidity, sensor_name: sensor.davis_luchtvochtigheid, sensor_state: <state sensor.davis_luchtvochtigheid=74; unit_of_measurement=%, friendly_name=Davis Luchtvochtigheid, icon=mdi:water-percent @ 2020-07-01T17:55:39.678731+02:00>
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state state value: 74
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for instance Smart_Irrigation, type: Hourly Adjusted Run Time, source: use_owm_windspeed, sensor_setting: sensor_windspeed, sensor_name: sensor.davis_windsnelheid_gemiddeld, sensor_state: <state sensor.davis_windsnelheid_gemiddeld=7; unit_of_measurement=km/h, friendly_name=Davis Windsnelheid Gemiddeld, icon=mdi:weather-windy @ 2020-07-01T17:55:34.125914+02:00>
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state state value: 7
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state USING A SENSOR for instance Smart_Irrigation, type: Hourly Adjusted Run Time, source: calculate_solar_radiation, sensor_setting: sensor_solar_radiation, sensor_name: sensor.davis_zonnestraling, sensor_state: <state sensor.davis_zonnestraling=345; unit_of_measurement=W/m², friendly_name=Davis Zonnestraling, icon=mdi:white-balance-sunny @ 2020-07-01T17:54:19.678605+02:00>
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state state value: 345
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] rain: 12.4, snow: 0.0
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] calculated evapotranspiration: 5.251584444387648
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] Calculated water_budget = 0 and adjusted_run_time: 0 for type: Hourly Adjusted Run Time. Bucket value was: 7.1484155556123525, and base schedule index is:<PHONE_NUMBER>095604, force mode is: False, force mode duration is: 0, lead_time is: 0, maximum_duration: -1, change percentage: 1.0, type: Hourly Adjusted Run Time
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state: just updated hourly_bucket_list: [7.1484155556123525, 7.1484155556123525]
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation] registering: type: Daily Adjusted Run Time, entity: sensor.smart_irrigation_daily_adjusted_run_time
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] async_added_t_hass type: Daily Adjusted Run Time state: 0, attributes: {'water_budget': '0.0 %', 'bucket': '0.0 mm', 'lead_time': '0 s', 'maximum_duration': '9000 s', 'adjusted_run_time_minutes': '0.0 min', 'force_mode_duration': 0, 'force_mode_enabled': False, 'unit_of_measurement': 's', 'icon': 'mdi:sprinkler', 'friendly_name': 'Daily Adjusted Run Time'}
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] async_added_t_hass type: Daily Adjusted Run Time, attribute: water_budget, attribute_value: 0.0 %, numeric_part: 0.0, show_units: False, a_val was str or contained ' ': True
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] async_added_t_hass type: Daily Adjusted Run Time, attribute: bucket, attribute_value: 0.0 mm, numeric_part: 0.0, show_units: False, a_val was str or contained ' ': True
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] async_added_to_hass restoring state, settting bucket to: 0.0
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] async_added_t_hass type: Daily Adjusted Run Time, attribute: adjusted_run_time_minutes, attribute_value: 0.0 min, numeric_part: 0.0, show_units: False, a_val was str or contained ' ': True
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state for type: Daily Adjusted Run Time
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] Calculated water_budget = 0 and adjusted_run_time: 0 for type: Daily Adjusted Run Time. Bucket value was: 0.0, and base schedule index is:<PHONE_NUMBER>095604, force mode is: False, force mode duration is: 0, lead_time is: 0, maximum_duration: -1, change percentage: 1.0, type: Daily Adjusted Run Time
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] calculating wb and art for daily adjusted run time, result: {'wb': 0, 'art': 0}
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] update_state for type: Daily Adjusted Run Time
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] Calculated water_budget = 0 and adjusted_run_time: 0 for type: Daily Adjusted Run Time. Bucket value was: 0.0, and base schedule index is:<PHONE_NUMBER>095604, force mode is: False, force mode duration is: 0, lead_time is: 0, maximum_duration: -1, change percentage: 1.0, type: Daily Adjusted Run Time
2020-07-01 17:55:41 INFO (MainThread) [custom_components.smart_irrigation.sensor] calculating wb and art for daily adjusted run time, result: {'wb': 0, 'art': 0}
Now it calculated the ET value correctly. I think modifying general settings does introduce the bug.
I'm away for an hour, when it updated again i will modify the integration setting it just as before to see if this introduces the problem,

well, something looks still off: https://pastebin.com/LPutaAKy
still see the message " skipped calculating evapotranspiration, got the following value from a sensor: 0.0"

yeah - I am working through refactoring stuff and testing it some more on my end. I think I have solar radiation working now. ET-from-a-sensor scenario looks better now as well. Give me a couple of minutes to wrap this into a new release. I got rid of the sources tracking (with the booleans) since it was really confusing - everything works on just the list of sensors now. It looks better on my end, but again, I am just using fake sensors.

new beta release is available now: https://github.com/jeroenterheerdt/HAsmartirrigation/releases/tag/v0.0.57

ok updated the code and restarted HA: https://pastebin.com/dB2dv0vh

@posixx - which scenario is this paste for? It would be helpful if I know what I am looking at :) is this a scenario with solar radiation sensor or skipping ET calculation alltogether by supplying a sensor for ET?

And after 5 minutes: https://pastebin.com/k9EhVFFX
Looks good now!

I'm not testing using ET sensor as that is working fine in my production HA. This is for scenario WITH solar radiation sensor and WITHOUT ET sensor

this one was triggered after modifying intrgration settings: https://pastebin.com/JxaZTxJp
Still working. What i don't get is why it calculates evapotranspiration 6 times withing the same second?

cool - thanks - not sure why the calculations happens multiple times, unless you have multiple instances configured.

for my own sanity - if you are willing, please test the latest release with your ET sensor scenario as well (so skipping the calculations all together) so we know it still works :)

OK updated and restarted production HA; all looks good:

Let's see what the daily calculation does at 23:55: it has rained a lot today (13,8 mm) so this should give some negative bucket value right?
On devsystem i see hlourly sensor value:

It looks like the last screenshot is correct. I think the ET value you are getting from the sensor is just the ET value, not the "net" precipitation (precipitation - ET). If that is the case I am not sure the way the code works now is correct, because when you choose the option to enter a ET sensor, we skip all of the other config as I assumed it would be a "net" ET sensor, not just the ET. I can see if I can make that change back somehow, because it seems pretty clear that the ET sensor you have is just the ET, not the "net" precipitation.

Results after calculating daily runtime:
Using all sensors:

Using ET sensor:

So indeed the ET sensor doesn't calculate rain / snow.
I think we need to skip the ET sensor and only use the real sensors for calculation.

right... or.... use the ET sensor for what it is but still provide the option to specify a precipitation sensor. because the combination would be all you need to calculate the 'net precipitation'. I will make some more changes soon! Thanks for all the testing!

https://github.com/jeroenterheerdt/HAsmartirrigation/releases/tag/v0.0.59 is ready - this changes the behavior of the ET sensor option and I think this is what we should be doing. let me know if it works correctly now.

Ok, uploaded new version but i don't see the option to add the precipitation sensor? I can only configure the ET sensor.

so... this is what I am seeing:

and then in the next step:

are you not seeing the same?

:-) awake again. After restart i see the new wizard screen. Added both intergations using these 2 sensors, it looks good:

awesome! so you can confirm both scenarios work now? should we wait until tomorrow morning (for you) before we finalize this?

Both scenario's work; i cannot comment on the values calculated as it looks these scenario's are completely different. My suggestion is to wait until tonight to see if calculated daily sensors are comparable.
component not using ET but actual weahterstation sensors:

component(s) using ET and rain sensor:

cool, let's wait to see what it looks like for the daily and if it looks good we can wrap this up :)

Ok so here it is:
Hourly and daily using ET calculation:

Hourly and daily using ET and rain sensors:

bucket value was the same for both environments. Calculation of the first doesn't seem to be ok?

What was the bucket before the update happened? Was it zero? I doubt it, but what was it?

It was 13.x something.. Don't know the exact value anymore.

hmm, it is hard for me to understand what is going on here. can you reset or write down the bucket value before the update happens so we can troubleshoot? Please post the screenshots as well

Ok values of Hourly and Daily sensors at 11:45:

Will post updated sensor values in about 10 minutes

Ok so hourly didn't change, Daily bucket updated:

this looks good to me - I checked the numbers. Did you have rainy weather the last couple of days? The bucket is 12.44 mm now (after the update) and today the net precipitation is > 0 (0.53 mm) so the calculations look fine, but I just want to make sure that your experience is the same.

Yes it was a rainy day. I will look at the values of production tonight (which is using ET and rain sensor) to see if results are the same

the same might be asking for too much, but similar, yes, hopefully that is the case :)

OK, whites are DEV, blacks are PROD:

After 23:55 / daily calculation:

Both calculations add/remove netto precipitation from bucket value. In case of ET sensor (= black screens) this is correct, in case of using all weatherstation sensors (white screens) it looks to me the calculated netto precipitation is not correct; this should be average of all hours combined.

And the log from DEV:
2020-07-07 23:55:00 INFO (MainThread) [custom_components.smart_irrigation] Updating for last time today, calculating adjusted run time for next irrigation time!
2020-07-07 23:55:00 INFO (MainThread) [custom_components.smart_irrigation] ENTERING _update_last_of_day. bucket is 12.44702653775455
2020-07-07 23:55:00 INFO (MainThread) [custom_components.smart_irrigation] using OWM for precipitation: False
2020-07-07 23:55:00 INFO (MainThread) [custom_components.smart_irrigation] bucket_delta set to -0.935988357053827, which is the last item in the hourly bucket list: [-0.5092992142981276, -0.5092992142981276, -0.5016480038194464, -0.5016480038194464, -6.803924512283468, -6.803924512283468, -6.988053812097904, -6.988053812097904, -2.959287851299875, -2.959287851299875, -2.307660823628767, -2.307660823628767, -5.685743432961742, -5.685743432961742, -4.448010489006721, -4.448010489006721, -9.219427526104127, -9.219427526104127, -6.659999570202846, -6.659999570202846, -4.102193937051903, -4.102193937051903, -2.5169598627963707, -2.5169598627963707, -1.265911456360866, -1.265911456360866, -1.0046571769184682, -1.0046571769184682, -0.5782054736447511, -0.5782054736447511, -0.935988357053827, -0.935988357053827]
2020-07-07 23:55:00 INFO (MainThread) [custom_components.smart_irrigation] Updating bucket: 12.44702653775455 with netto_precipitation: -0.935988357053827, which should be average or last value of: [-0.5092992142981276, -0.5092992142981276, -0.5016480038194464, -0.5016480038194464, -6.803924512283468, -6.803924512283468, -6.988053812097904, -6.988053812097904, -2.959287851299875, -2.959287851299875, -2.307660823628767, -2.307660823628767, -5.685743432961742, -5.685743432961742, -4.448010489006721, -4.448010489006721, -9.219427526104127, -9.219427526104127, -6.659999570202846, -6.659999570202846, -4.102193937051903, -4.102193937051903, -2.5169598627963707, -2.5169598627963707, -1.265911456360866, -1.265911456360866, -1.0046571769184682, -1.0046571769184682, -0.5782054736447511, -0.5782054736447511, -0.935988357053827, -0.935988357053827]
2020-07-07 23:55:00 INFO (MainThread) [custom_components.smart_irrigation] hourly_bucket_list is now empty, bucket is 11.511038180700723
2020-07-07 23:55:00 INFO (MainThread) [custom_components.smart_irrigation] Bucket for today is: 11.511038180700723 mm
2020-07-07 23:55:00 INFO (SyncWorker_5) [custom_components.smart_irrigation.sensor] _bucket_updated, received bucket value 11.511038180700723 from event_dict: {'event_type': 'Smart_Irrigation_bucketUpd', 'data': {'bucket': 11.511038180700723}, 'origin': 'LOCAL', 'time_fired': datetime.datetime(2020, 7, 7, 21, 55, 0, 3054, tzinfo=), 'context': {'id': 'aea0baefe86d4d0c9d29f204d603f4b3', 'parent_id': None, 'user_id': None}}
2020-07-07 23:55:00 INFO (SyncWorker_5) [custom_components.smart_irrigation.sensor] updated_adjusted_run_time_from_event called.
2020-07-07 23:55:00 INFO (SyncWorker_5) [custom_components.smart_irrigation.sensor] Calculated water_budget = 0 and adjusted_run_time: 0 for type: Daily Adjusted Run Time. Bucket value was: 11.511038180700723, and base schedule index is:<PHONE_NUMBER>095604, force mode is: False, force mode duration is: 0, lead_time is: 0, maximum_duration: 9000, change percentage: 1.0, type: Daily Adjusted Run Time
2020-07-07 23:55:00 INFO (SyncWorker_5) [custom_components.smart_irrigation.sensor] updated_adjusted_run_time_from_event: got result: {'wb': 0, 'art': 0}. Setting attributes of daily adjusted run time (including result['wb']) and state == result['art']
Looking forward reading your comments in the morning:-)

thanks for providing the logs - so the DEV environment is doing as it is supposed to do - it is getting the latest value for precipitation and using that - since you are using a sensor that accumulates during the day this is what is expected. not sure why you think this should be different - didn't we agree before that you use the most recent value for precipitation when using a sensor for it and otherwise the average? that is exactly what is happening here.

No DEV is calculating hourly precipitation based on weatherstation sensors, so this should calculate the average of all hourly calulations right? PROD is using ET value which is calculated by the weatherstation and the hourly value at 23:55 is the netto precipitation without rain.

no - if you use a sensor for precipitation from a weatherstation we take the most recent value as it is expected to accumulate during the day (as yours does based on your screenshots before - see earlier in this thread) and smart weather does the same. so taking the most recent value is the appropriate action here.

Sorry Jeroen, but I think you are mixing up DEV and PROD. On the PROD screenshot you see precipitation building up during the day up to 2.896 mm. This is the ET sensor from my weatherstation.

To me the solution is simple: DEV should calculate average over all hourly values, not taking the last:
2020-07-07 23:55:00 INFO (MainThread) [custom_components.smart_irrigation] bucket_delta set to -0.935988357053827, which is the last item in the hourly bucket list: [-0.5092992142981276, -0.5092992142981276, -0.5016480038194464, -0.5016480038194464, -6.803924512283468, -6.803924512283468, -6.988053812097904, -6.988053812097904, -2.959287851299875, -2.959287851299875, -2.307660823628767, -2.307660823628767, -5.685743432961742, -5.685743432961742, -4.448010489006721, -4.448010489006721, -9.219427526104127, -9.219427526104127, -6.659999570202846, -6.659999570202846, -4.102193937051903, -4.102193937051903, -2.5169598627963707, -2.5169598627963707, -1.265911456360866, -1.265911456360866, -1.0046571769184682, -1.0046571769184682, -0.5782054736447511, -0.5782054736447511, -0.935988357053827, -0.935988357053827]
These values are all calculated using temperature / humidity / solar radiation sensors, what’s the point of that if you only use the last value..

ok, I might be wrong here then, but I think we are just confusing multiple things here. happy to change the behavior, but we need to be crystal clear about which scenario we need to do what. Right now the update is happening hourly, so the bucket_delta list is updated hourly. That makes sense in all scenarios. Now, the trick is of course to figure out which item from the bucket_delta list to take. here I see two scenarios:

average - this is applicable when the values calculated are on point-in-time basis.
most recent - this is applicable when the values are based on accumulative sensors, such as what is the case with precipitation-during-the-day sensors as provided by most weather stations and smart weather.

Currently the logic is:
if we use OWM for precipitation we take the average of the bucket_delta list. In all other cases we get the most recent value of the bucket_delta list. Given that OWM is point-in-time I think that part is correct, but if we do not use OWM it becomes more tricky.
Basically the bucket_delta is precipitation - evapotranspiration. So, if you use a cumulative sensor for precipitation (which is expected) taking the most recent bucket_delta is the correct behavior. Keep in mind that at the time the bucket_delta list entry is calculated we still take whatever the value at that point is for solar radiation, humidity, temperature, etc (point-in-time values).
Just precipitation is accumulative, so whenever we use a sensor for that we need to take the most recent `bucket_delta, NOT the average.
whether or not you specify a ET sensor does not matter here since that only tells us if we need to estimate evapotranspiration or we can just get value from a sensor - it only influences the second part of the bucket_delta calculation.
So I think the behavior is as it should be - precipitation sensors are normally cumulative during the day so taking the most recent entry from bucket_delta is correct as it is precipitation - evapotranspiration. When using a point in time value for precipitation (really only when using OWM) we take the average of bucket_delta.

Hello Jeroen,
I did send you a link to see how Davis is calculating ET: https://www.davisinstruments.com/product_documents/weather/app_notes/AN_28-derived-weather-variables.pdf
As you can see at the hourly screenshot this is clearly a accumulated sensor which is reset to 0 at 0:00h:

BTW i use light theme during the day and switch to dark theme at nigt on PROD, so don't focus to much at white or black:-)
If i look at the values of the weatherstation ET calculation is calculated without rain (which is also a accumulated sensor):

So i would think the current ET sensor implementation is correct; You take the last value of ET sensor - last value of rain sensor = netto precipitation.
As the rainsensor is accumulated and the other sensors used in calculations aren't; to me it woul be better to calculate evapotranspiration based on sensors every hour WITHOUT rainsensor, and when calculating daily evapotranspiration take average of all hourly evapotranspiration values - accumulated rain sensor.

ok, so apart from the last bit (which I don't think makes a lot of impact) we're good to go?

Well; i think the daily values using real sensors need to be comparable to the daily values using ET/rain sensor. But apart from that were good to go!
If i'm adding up all hourly values and devide this by the number of calculations i get 3.4, which is a lot more comparable using ET sensor, which was 2,9

In your case I would go with ET sensor, since that is bound to be the most accurate. Other options in decreasing order of accuracy: would be going with sensors with solar radiation, sensors without solar radiation and OWM.

thanks for confirming!

Yes ET + rain will be my choice. I will upgrade to v0.0.62 to help regarding #42 so we can have a new Release shortly hopefully

@posixx you will be happy to learn that I have given this more thought and made a new release: https://github.com/jeroenterheerdt/HAsmartirrigation/releases/tag/v0.0.64. I have changed the behavior and will write it up in the documentation so there is less chance for us getting confused by the various scenarios.

write up of the calculation behavior is here: https://github.com/jeroenterheerdt/HAsmartirrigation#getting-the-best-results. Please let me know if this makes sene.

Fantastic, this is exactly how we get the most acurate results. Great work Jeroen!

hey, all thanks to you. it took me a little bit to fully grasp where we needed to go and you kept me honest. Thanks for providing the feedback. Happy to close this though :)

The fao56 function of pyeto wants the solar radiation in MJ per m² and day, thats an energy.
But the wiki says that solar radiation is in W/m², this is the current power. I think this is wrong.


I wonder what is the shape of y_repd in AC loss?

Hi @xuuuuuuchen
In another issue, you said that the input shape in AC loss is [Batch, 1, W, H].
Dose  it mean that the y_pred is an output of softmax layer followed by an argmax operator or a pick operator to pick out the probability of fg(or bg)?
If the shape of y_pred is [Batch, 1, W, H], why do you pick the first channel (y_pred[:, 0, :, :]) when you implement the Eq[12] but not do so when you implement the Eq[11] ?

Hi @haozhi1817 ,

y_pred is an output of the sigmoid layer because it is a 2-class segmentation problem.
It depends on how you pre-define the shape C_1/_2. If the shape of C_1/_2 was firstly defined as np.ones/zeros((256, 256)), y_pred must has same size like [:, 0, :, :]. You could use y_pred directly without slicing out the 1st channel, if so, C_1/_2 need to be pre-defined as np.ones/zeros((1, 256, 256)).

class ActiveContourLoss(Module):
def init(self):
super(ActiveContourLoss, self).init()
def forward(self, y_pred, y_true, combine=None):

    x = y_pred[:,:,1:,:] - y_pred[:,:,:-1,:] # horizontal and vertical directions
    y = y_pred[:,:,:,1:] - y_pred[:,:,:,:-1]

    delta_x = x[:,:,1:,:-2]**2
    delta_y = y[:,:,:-2,1:]**2
    delta_u = torch.abs(delta_x + delta_y)

    epsilon = 0.00000001 # where is a parameter to avoid square root is zero in practice.
    w = 1.

    if combine is not None:
        lenth = w * torch.mean(torch.sqrt(delta_u + epsilon)) # equ.(11) in the paper
    else:
        lenth = w * torch.sum(torch.sqrt(delta_u + epsilon)) # equ.(11) in the paper

    if torch.cuda.is_available():
        C_1 = torch.ones(y_true.shape, dtype=torch.float32).cuda()
        C_2 = torch.zeros(y_true.shape, dtype=torch.float32).cuda()
    else:
        C_1 = torch.ones(y_true.shape, dtype=torch.float32)
        C_2 = torch.zeros(y_true.shape, dtype=torch.float32)

    if combine is not None:
        region_in = torch.abs(torch.mean(y_pred * ((y_true - C_1)**2)) ) # equ.(12) in the paper
        region_out = torch.abs(torch.mean((1. - y_pred) * ((y_true - C_2)**2))) # equ.(12) in the paper
    else:
        region_in = torch.abs(torch.sum(y_pred * ((y_true - C_1)**2)) ) # equ.(12) in the paper
        region_out = torch.abs(torch.sum((1. - y_pred) * ((y_true - C_2)**2))) # equ.(12) in the paper

    lambdaP = 5. # lambda parameter could be various.
    loss = lenth + lambdaP * (region_in + region_out)

    return loss


Return 404 NotFound if requested attachment does not exist

Add code to test if GetAttachmentByID returns an ErrAttachmentNotExist error
and return NotFound instead of InternalServerError
Fix #20884
Signed-off-by: Andrew Thornton<EMAIL_ADDRESS>

make lgtm work


pricing page text overlap on smaller screens

Problem description
noticed that theres some text overlap on the pricing page for smaller screens

this is old our pricing page is different now


feat: 🎸 Support account type string for secondary accounts

Description
Changes the account type in ModifySignerPermissionsParams from Account to string | Account. This allows us to pass address of the account directly while modifying/revoking permissions for a secondary account.
This change is required for REST API
Breaking Changes
NA
JIRA Link
DA-47
Checklist

[ ] Updated the Readme.md (if required) ?

:tada: This PR is included in version 18.0.0-beta.6 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Fix Driver Compile Bug

This patch fixes an issue with the Linux kernel that prevented
the Bareflank driver from compiling on older versions of Linux
as the cr4_init_shadow did not exist until Linux 4.0
Signed-off-by: Rian Quinn<EMAIL_ADDRESS>

All checks pass, merging.


update dependencies

Check if we can update @opentelemetry/* dependencies
(+ improve dependabot settings?)
(+ improve test setup and coverage?)

https://github.com/cap-js/telemetry/pull/208


Script now crashes on login

I'm receiving the following error when running the script:

When inspected, the email input field's id is "email" instead of "usernameOrEmail", so I guess Epic changed that around. Has this ever happened before?

Yeah, I just checked and you're right: they changed it to just email.
I know for a fact that this used to be username and email but now it seems they verify solely based on email. I'll update this, so don't worry about having to change it in yours.
And thanks for pointing that out!

Just fixed. Thanks again!


Change variable name test_data > validation_data

it is confusing to name validation data test_data especially as terms like train, validation, test splits are common in ML. Change variable name in python quick start.

never mind, the variable name works in this context, I'm confusing things.

please merge the latest master branch to ensure the test-passing.


Azure VM Connection Troubleshooting

In Azure portal, Azure VM blade, there is a tool called "connection troubleshooting"
My first question is where this feature is documented?
My second question is, What RBAC permission is required in order to run connection troubleshooting from VM blade?
If I understand correctly, it calls network watcher rest api https://docs.microsoft.com/en-us/rest/api/network-watcher/networkwatchers/getnetworkconfigurationdiagnostic
I logged on using an identity without any network watcher permission, and it worked.
Please provide your guidance and I appreciate your help!

[Enter feedback here]

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

ID: cf1e39d6-8fde-4706-b223-72f3ec821728
Version Independent ID: 36bb1852-e473-de66-af60-046484919a3b
Content: Troubleshoot connections - Azure portal - Azure Network Watcher
Content Source: articles/network-watcher/network-watcher-connectivity-portal.md
Service: network-watcher
GitHub Login: @damendo
Microsoft Alias: damendo

@RonnieQuan , to answer your first question, you can find the "Connection troubleshoot" feature documented in the below articles:
https://docs.microsoft.com/en-us/azure/network-watcher/network-watcher-connectivity-overview
https://azure.microsoft.com/en-in/blog/network-watcher-connection-troubleshoot-now-generally-available/
Regarding your second question on what RBAC permissions are required in order to run connection troubleshoot, you can refer the below article:
https://docs.microsoft.com/en-us/azure/network-watcher/required-rbac-permissions#connection-troubleshoot
To use Network Watcher capabilities, the account you log into Azure with, must be assigned to the Owner, Contributor, or Network contributor built-in roles, or assigned to a custom role that is assigned the actions listed for each Network Watcher capability as mentioned in the above article. Hence, if you logged into Azure with Owner, Contributor, or Network contributor built-in roles, you do not need to assign any specific RBAC permissions to run Connection troubleshoot.
We are closing this issue for now. If there are further questions regarding this matter, please reply and we will gladly continue the discussion.


Fix bitsandbytes h100 issue

Makes load_8_bit optional, defaults to current value.
NOTE: the PR automation was already broken before this PR - see https://github.com/arcee-ai/DALM/pull/94

@tleyden 🔥 🙏

Do it!


Scoped slot

About scoped slots:
please read this line in doc.

A more typical use case for scoped slots would be a list component that allows the component consumer to customize how each item in the list should be rendered:

So inspired on above line I have create an example that try to allow consumer to customize how child data is listed. I use list-style. but as per your above comment I can also customize it to html table format.
Now suppose in list-style I am facing one issue. can you please suggest on it. check below code.

    <child-component :pass-items="itemList">
        <template slot="myItemSlot" scope="mscopevars">

{{mscopevars.currentitem}}

        </template>
    </child-component>

Here output of this example contain a p tag inside ul tag. this is because I have add p tag in component template. But I have no scope to render template without any parent tag or I can not just put only slot tag in above template. I must have to wrapper it with some tag so I put p tag. but basically it wrong to have p tag inside ul tag right? it must be li tag. so what is the proper solution for it?

For usage questions like this, I recommend posting your question on either the forum or Discourse chat. We try to reserve issues for bugs and feature requests. To get you started on the right track though, check out the is attribute.

Hi Chris,
I already know about "is" attribute. but for above example "is" attribute not fit. I already have  tag that is used to pass itemList. so I can not define another component to  tag using is attribute.
Or can you please give me modified version of above example using "is" attribute?
Thanks for your reply.


Use tsvector for full text search, or allow custom filters

Is your feature request related to a problem? Please describe.
We're looking to leverage tsvector for our full text search, but we really like Flop for all the param/filter handling that it can do.
Some discussion from the postgres documentation on why tsvector is awesome for full text search
Describe the solution you'd like
This library might not want to tie itself directly to postgres, so one potential option is to allow us to roll some custom filters in the API. I scanned the hexdocs, but it doesn't look like there's support for that at the moment.
Describe alternatives you've considered
We're very happy to contribute a PR to help unblock this issue, either for supporting tsvector or custom filters! Whatever supports the direction that Flop is looking to grow into.
Additional context
cc @nathan-yuen

Thanks for opening the issue. We have custom fields, which should allow you to model this: https://hexdocs.pm/flop/Flop.Schema.html#module-custom-fields

Thanks! We'll give that a try!


Webhook payload should return timestamp and a unique ID

It would be helpful to have an authoritative timestamp of events generated on the server. For event processing, having a unique ID for each callback would help server processing to be idempotent.

:fireworks:


Incorrect displaying of map after changing

I've changed my community in iD. So, it was changes since 15.02.2018 16:00
So, when I open OSM (not editor) first time (today) I didn't see any changes, but I saw, in different scales you can see changes, but incorrectly.
1st screenshot - Map in editor

2nd screenshot - Map after changes

3d screenshot - Map after changes in another scale

Hi @lujo777 - first, thank you for your edits!
What you're seeing is expected.  The rendered map on openstreetmap.org might not display the latest edits right away.  It takes some time (usually a few minutes) to update, and this will happen differently at different zoom levels.
The data that you see in the iD editor is the raw OSM data that is current as you navigate around the map.
https://wiki.openstreetmap.org/wiki/FAQ#I_have_just_made_some_changes_to_the_map._How_do_I_get_to_see_my_changes.3F

So, when we can see full changes?

So, when we can see full changes?

I don't know - it's not related to this project.
The FAQ I linked to has some info, and that contains links to some longer explanations:
https://wiki.openstreetmap.org/wiki/FAQ#I_have_just_made_some_changes_to_the_map._How_do_I_get_to_see_my_changes.3F


re-template matern32 prim

Description
To include the divide_columns function matern52 must be templated differently. I've included these updates in the following PR.
I'll adjust gp_matern32_cov, exponential and gp_exp_quad_cov as well in this way.

The bug was that it passes test cases, but would not compile with command stan. The changes allow it do to so.

The same tests cases are fine, as even though something passes all test cases internally, does not mean the C++ code generated will compile. So I had to adjust the templating accordingly. So, the new test case is "compile model with cmdstan". This doesn't fit within the realm of a "unit test".

Current Math Version
v2.18.0

@bbbales2 see the updates to this commend addressing some of your concerns in #982. In summary, unit tests with C++ do not ensure code generated within cmd-stan will compile, and these fixes address that.

This shouldn't be an issue with CmdStan specifically.  All CmdStan does is call Stan's compiler.
Checking that Stan programs can be compiled is definitely within the scope of our unit tests.  We have a directory test/test-models/good and every model in there is checked for compilability.  All possible instantiations of functions that are being added (in terms of int, double, and var).

Just to be clear.  The unit tests should be sufficient to guarantee that the code will compile through the interfaces.  If something didn't work through CmdStan, then this should be tackled by first adding a unit test that fails with the current implementation, then fix the problem.  That test will then become what's known as a "regression" test to make sure we don't reintroduce the bug later.


PERF: N4BiasFieldCorrectionImageFilter adds points + weights ~20% faster

N4BiasFieldCorrectionImageFilter::UpdateBiasFieldEstimate now adds the points
and weights for the internally used BSplineFilter in a much faster way than
before, by:

Reserving the memory needed to store the data beforehand.
Directly doing push_back on the STL containers from the internally used
itk::PointSet and itk::VectorContainer.

Using VS2015 (Release), approximately 20% reduction of the run-time duration was
observed (from 70 down to 56 seconds) on a 3-D MRI volume + mask (453x340x20),
provided by Denis (@dpshamonin), at LKEB, Leiden University Medical Center.

@ntustison FYI, here is my third PERF pull request this year, for your bias correction filter! (The previous two PERF commits pull requests have been merged already:  20c4a418eba6f13f177fa7a8036d02fd3853b7e1 and a77af2a338a01c04379571be0b77c0a322b17d4f.) Compared to ITK4, I observed a total performance improvement from these PRs of more than 35% on an Update() of your filter!


chore: add typescript build config

This PR adds the typescript build configuration to the package

@monitz87 - Forward-integration (+ resolved conflicts) after merging #7 to master (build:dev and build:prod good still)

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Release 0.0.2

Fix the teaser code in Readme (#4)

Pull Request Test Coverage Report for Build 628041795

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 96.121%

Totals

Change from base Build 628038803:
0.0%

Covered Lines:
223

Relevant Lines:
232

💛  - Coveralls


'Start-download' button shows notifications when disabled

If no URL is provided then 'Start-download' button appears to be disabled. However, when clicked, it works as if it was enabled.

I've fixed the issue and in the next update it should work correctly.


Comparing development status to the 7 services

Work Request
The ETOR Intermediary service definitions can be found here - https://aphlinformatics.atlassian.net/l/cp/f5EgPMBA
In the MVP Requirements Matrix, I have added a tab called "Mapping to the 7 services," please populate column C with Flexion's current completed capabilities. You can find the most up to date file here: https://aphlinformatics.atlassian.net/wiki/spaces/IR/pages/1820852269/Reference+Materials+-+Intermediary+Development#ETOR-MVP-Requirements-Matrix
Anticipated Ticket Size
Assign a size for this ticket.  Use "t-shirt sizes".

Small: One person for half a day or less.

Anticipated Urgency Level
Assign an urgency level for this ticket.

Urgent: Request within the current sprint (may impact current work in progress).
Complete by EOD November 3

Other Notes

Any other notes to help clarify this task for the team.  Please link or attach a document to the ticket if one exists.

Flexion response attached 02Nov_Master Requirement Matrix - APHL_Flexion - Flexion response.xlsx.
And saved to shared drive CDC TI/MVP/


Update Extended Report APIs

This is a set of commits to update the extended report API to return the contents of the report and the certificates in a rust-friendly way. It also adds derived serialization and de-serialization to the associated data types to allow easier marshaling between services.
Addresses #43
Signed-off-by: Larry Dewey<EMAIL_ADDRESS>

Like mentioned above, there's still some of the low-level syscall details of getting a report that a user doesn't care much for.

Again, I am not entirely sure what low-level syscall details you are referring to?


Provide the getTopNApplicationThroughput query.

H2 DAO's implementation is empty.
INPUT
{
  getTopNApplicationThroughput(duration: {start: "2017-01", end: "2018-02", step: MONTH}, topN: 10) {
    applicationId, applicationCode, tps
  }
}

OUTPUT
{
  "data": {
    "getTopNApplicationThroughput": [
      {
        "applicationId": -1,
        "applicationCode": "dubbox-consumer",
        "tps": 0
      },
      {
        "applicationId": 2,
        "applicationCode": "dubbox-provider",
        "tps": 0
      }
    ]
  }
}

Coverage increased (+0.004%) to 20.908% when pulling 71275468c59404076014c1befa9e3d05c3a22b7f on peng-yongsheng:feature/getTopNApplicationThroughput into 59ae085b1c9481a09844aed4c6f1a957f450fd22 on apache:master.

FYI @hanahmily


4.0.dev32

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

@conda-forge-admin, please rerender

Merge when ready, @cmutel.


Solution to the task 1 template

This is my solution to task 1.1 using the task 1 template to move to the positions shown in the video.

Task 2 works for me as well. nice work!

Task 2 works for me as well. nice work!


Interact with Token on localhost using testrpc, Metamask, and truffle

I've been using truffle to deploy contracts via a localhost, and using metamask to interact with the dapp.  I am wondering if I can load that contract for this token into tokenfactory?  When I access the tokenfactory website I can't use it unless I have metamask installed.  So, Im just assuming that if I have metamask connected to a private network then any way I interact with token factory will also be on localhost (a side note is if I am not on local host then do I have to pay the gas fee to create the tokens over the mainnet?)
When I try to interact with a token (for example using the metacoin.sol test token from truffle)  I use the metacoin address provided after running truffle serve.  The procedure brings up:

Interacting with token at address: 0x0ef790110aa9fded64c8dff1d8d96be05c8a5024.
Total Supply is: .

How can I interact with this token I created and served using truffle using the token factory interface?  Am I missing something like not adding the correct contract address?

If you are connected to testrpc from Metamask, the token deployed through truffle, you should be able to interact with, through Token Factory.
However, metacoin.sol in the Truffle example is not ERC20-compliant and won't work in Token Factory. cc @tcoulter.

Hey @Canalytic! iirc, your issue was that metacoin wasn't compliant with ERC20. Can I close this? :)

Yes, please


feat: Package controller

Signed-off-by: Yashvardhan Kukreja<EMAIL_ADDRESS>

in favor of #67


Fix error in exec commands when master url does not have a trailing slash

Fixes #2414

No sneaking in features. :)
There's some experimental commit...

Yeah looks like I didn't branch from master

Experiment eradicated

This will most likely conflict with #2412

Yeah, rebase needed now


Files missing in the TrustKit_Static target

Thanks for the library and the great changes in the new release!
In the 1.5.0 release, TSKPinningValidatorResult.m and TSKSPKIHashCache.m are not included in the TrustKit_Static target. This causes a build failure when using the Embedding TrustKit Without CocoaPods approach that had its description removed in https://github.com/datatheorem/TrustKit/commit/e61d7d053fa4af82e5789be2a7b13d31fc9f6821
Also, it'd be great if breaking API changes like the ones in 1.5.0 were introduced in a major version bump for clarity.

It has been released as part of v1.5.1.


Allow user to load custom modules as pickles

Similar to Tempo, we could add a new built-in MLServer runtime (e.g. mlserver.PickleRuntime), which knows how to unpickle a MLServer runtime (i.e. looking for a particular class name).
Likewise, we would need some sort of helpers within the mlserver package which handle the pickling to ensure that users can save their runtimes easily.
Example
For embedded / non-reusable use cases (i.e. where the runtime doesn’t depend on any external artefacts), the expected model layout in the model repository, would look along these lines:
/mnt/models/<model-name>/
|----- runtime.pickle
|----- model-setings.json

Where the model-settings.json file would look like:
{
  "name": "<model-name>",
  "implementation": "mlserver.PickleRuntime",
  "parameters": {
    "runtime": "./runtime.pickle"
  }
}

Alternatively, for reusable use cases (i.e. where the runtime needs to load external artefacts), the expected model layout in the model repository would look along these lines:
/mnt/models/<model-name>/
|----- runtime.pickle
|----- model-settings.json
|----- <model-artifacts….>

And the model-settings.json file would look like:
{
  "name": "<model-name>",
  "implementation": "mlserver.PickleRuntime",
  "parameters": {
    "uri": "<model-artifacts....>",
    "runtime": "./runtime.pickle"
  }
}

Following the addition of #694 , this use case should already be covered by adding plain *.py files. Therefore, it doesn't seem like pickles would add much value on top of the above.
Based on that, we'll be closing this one for now, but happy to reopen the discussion if someone can think of any points that wouldn't be covered by #694 .


Show statistics on map relative to population

Issue migrated from neuroactive/koroonakaart:
aomaesalu commented 2 days ago
Currently, the heatmap seems to be based on absolute values. However, as over 40% of the population lives in Harju county, that is going to define the map. Having a heatmap with values relative to the population of the corresponding counties could improve the overview of the spread of the virus. You could have a toggle to switch whether to use absolute or relative values, so the page would not get too convoluted with different charts.
neuroactive commented 2 days ago
Thanks for the feedback. That's a reasonable point, and we are looking to improve the options for how the graph is presented. We are somewhat limited by time and resources at present.
zidik commented 2 days ago •
Using the number of cases relative to number of inhabitants would really make sense for the heatmap; It would give a better sense of prevalence of the virus in the region.
But could this be skewed by the availability of the testing in each region? Would number of cases relative to people tested would make more sense?
aomaesalu commented 2 days ago
Yes, I agree with @zidik. However, is there information on the number of tests by county?
neuroactive commented 2 days ago
We are planning to make it possible to present the map using cases by number of inhabitants.
Unfortunately, county-level information about tests hasn't been made available to us yet.

The current provisional plan is to make it possible to browse any of the headline statistics (Confirmed cases, Active cases, etc) relative to the population in each county. However, traffic to the app is increasing fast, so first we need to spend some time improving the infrastructure before we tackle additional features.

Even if the county to population info is hard to get, the "tests to population" and "infected to population" would be a really good help.

We have added a graph showing total positive tests per 10,000 population now. Soon we hope to add this option to the map as well.

This has been implemented and once local changes are pushed it will be live.


Cosmic Blast

PR Description 📜
Created game Cosmic Blast ready to be integrated.
[New game] #3076

Mark the task you have completed ✅

[x] I follow CONTRIBUTING GUIDELINE & CODE OF CONDUCT of this project.
[x] I have performed a self-review of my own code or work.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] My changes generates no new warnings.
[x] I have followed proper naming convention showed in CONTRIBUTING GUIDELINE
[x] I have added screenshot for website preview in assets/images
[x] I have added entries for my game in main README.md
[x] I have added README.md in my folder
[ ] I have added working video of the game in README.md (optional)
[x] I have specified the respective issue number for which I have requested the new game.

![Cosmic_Blast](https://github.com/kunjgit/GameZone/assets/114163734/ef419ef2-5bc9-4203-a3b7-05ace67041c8)
Thank you soo much for contributing to our repository 💗

Thank you @vansh-codes ,for creating the PR and contributing to our GameZone 💗
Review team will review the PR and will reach out to you soon! 😇
Make sure that you have marked all the tasks that you are done with ✅.
Thank you for your patience! 😀

Thank you  @vansh-codes , for your valuable time and contribution in our GameZone 💗.
It’s our GameZone, so Let’s build this GameZone altogether !!🤝
Hoping to see you soon with another PR again 😇
Wishing you all the best for your journey into Open Source🚀


Don't clear selected log entry in structured logs if filters are removed

Currently the log entry is cleared if the filters change in any way. That's not strictly necessary if filters are only removed - the selection is necessarily still in the resulting set.

Original comment: https://github.com/dotnet/aspire/pull/2913#issuecomment-2002673138

I think this could be improved by only clearing the selection if a filter is added/changed, and not if a filter is removed.
For example:

Removing the text filter on resources/structured logs
Removing an advanced filter on the structured logs
Removing type filter on resources
Removing level filter on structured logs

Nice to have usability fix for 9.0, but can ship without

@leslierichardson95 tag this as a filter / sorting story issue later


split term: MONDO:0011876 name: juvenile absence epilepsy

Term to split:
MONDO:0011876 name: juvenile absence epilepsy
Name for new terms:
MONDO:0800453 juvenile absence epilepsy
MONDO:0800454 epilepsy, juvenile absence, susceptibility to, 1
Related to https://github.com/monarch-initiative/mondo/issues/6419

I was starting to work on this and see now there is already a term named MONDO_0020772 epilepsy, juvenile absence, susceptibility to, 1.
@nicolevasilevsky we talked about deprecating MONDO:0011876 name: juvenile absence epilepsy and creating 2 new terms for MONDO:0800453 juvenile absence epilepsy and MONDO:0800454 epilepsy, juvenile absence, susceptibility to, 1. How should this be handled?

Another way to look at the issue is as follow:
The concept of MONDO:0011876 (juvenile absence epilepsy) needs to be split because it includes 2 separate concepts:

concept 1: juvenile absence epilepsy
concept 2: epilepsy, juvenile absence, susceptibility to, 1

Concept 1 does not already exist in Mondo. We therefore need to create a new term to represent this concept, and give it a new ID. This ID was already chosen (to help users) and is MONDO:0800453. Annotations for this new term (synonyms, cross-references,...) will be some of the term being obsoleted/split
Concept 2, in this case, is already in Mondo (and represented by MONDO:0020772). Therefore, there is no need to create a new term. You just need to update the existing concept (ie MONDO:0020772) and add the relevant annotations from the term being obsoleted/split (e.g. synonyms, cross-references,...) to this term.

Ok, that's what I thought. Does it need to be documented anywhere that MONDO:0800454 is not being used for "epilepsy, juvenile absence, susceptibility to, 1" when MONDO:0011876 (juvenile absence epilepsy) is deprecated?

No, there is no need to document that MONDO:0800454 was not used, because this ID was not used in Mondo.

Sure, it is mentioned in a comment on MONDO:0011876 (juvenile absence epilepsy) and in the ROBOT template.


Fixes resumable option not being passed to GSC

resumable option wasn't being passed to GSC

@alexgorbatchev Thank you for the contribution! I'll review https://github.com/syndbg/webpack-google-cloud-storage-plugin/pull/12 a bit later and cut a release in github and npm.

@alexgorbatchev Sorry for the wait. https://www.npmjs.com/package/webpack-google-cloud-storage-plugin/v/0.8.2 is released