Skip to content

Conversation

@kaskranenburgQ
Copy link
Contributor

@kaskranenburgQ kaskranenburgQ commented May 14, 2025

@kaskranenburgQ
Copy link
Contributor Author

This migration causes minor changes in comparison to beta, see the ii3050v2 NT Leadership scenario in which both removed sliders where set to 95%:
Beta:
Screenshot 2025-05-14 at 12 11 35

Local:
Screenshot 2025-05-14 at 12 12 03

I personally don't see how we could mitigate these changes, since there are no other sliders that influence the useful demand of lighting in the buildings sector. Since these changes are generally small, I feel that no extra effort is required.

@github-actions
Copy link

This pull request has had no activity for 60 days and will be closed in 7 days. Removing the "Stale" label or posting a comment will prevent it from being closed automatically. You can also add the "Pinned" label to ensure it isn't marked as stale in the future.

@github-actions github-actions bot added the Stale Issue had no activity for 60 days and will be, or has been, closed. label Jul 14, 2025
@github-actions github-actions bot closed this Jul 28, 2025
@kaskranenburgQ kaskranenburgQ added Pinned Will never be marked as stale or auto-closed. and removed Stale Issue had no activity for 60 days and will be, or has been, closed. labels Jul 28, 2025
@kndehaan kndehaan force-pushed the remove-intelligent-control branch from 8fe5084 to c74dbab Compare January 19, 2026 11:07
@kndehaan
Copy link
Contributor

I've updated the migration file name to be the most recent one. I agree with the conclusion that there's no way to account for the settings in the intelligent light control inputs with I migration. So the migration should just only remove the inputs from the scenarios.

@kndehaan kndehaan marked this pull request as ready for review January 19, 2026 15:56
@kndehaan kndehaan requested review from kndehaan and louispt1 January 19, 2026 15:56
@kndehaan
Copy link
Contributor

Added @louispt1 as a functional reviewer.

Copy link
Contributor

@kndehaan kndehaan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works as it should.

@kndehaan
Copy link
Contributor

kndehaan commented Jan 20, 2026

The migration will be altered, as the work for quintel/etmodel#4631 will be taken up as well, which will affect the migration.

@aaccensi aaccensi force-pushed the remove-intelligent-control branch from f8f16e2 to 49c4898 Compare January 29, 2026 12:48
@aaccensi aaccensi requested a review from noracato January 29, 2026 12:59
@aaccensi aaccensi marked this pull request as ready for review January 29, 2026 13:00
@aaccensi aaccensi requested a review from kndehaan January 29, 2026 13:00
Copy link
Contributor

@kndehaan kndehaan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The migration works well and shows the results that I expect from the pseudo code! The migration needs alterations on two points (this was not wrong about the migration itself, but what I found out after testing that was missing from the pseudo code). Point 1 can already be processed, point 2 I still need to figure out how this should be calculated correctly.

1. To be added to the migration
The old input buildings_useful_demand_for_appliances has been renamed to buildings_appliances_efficiency, so it needs to be checked if this input was set in a scenario and the value subsequently needs to be set for the new input name. Old input should be deleted. In pseudo code:

APPLIANCE_EFFICIENCY_OLD_KEY = 'buildings_useful_demand_for_appliances'
APPLIANCE_EFFICIENCY_NEW_KEY = 'buildings_appliances_efficiency'

if APPLIANCE_EFFICIENCY_OLD_KEY set in scenario:
  APPLIANCE_EFFICIENCY_NEW_KEY = APPLIANCE_EFFICIENCY_OLD_KEY
  delete APPLIANCE_EFFICIENCY_OLD_KEY

2. Modification in migration
There's something not going right in the use case where both demand and intelligent light inputs were set (elsif old_demand_set && intel_light_set), but that's something that goes wrong in the pseudo code (and therefore in the migration). I will try to figure out how this should be done properly, and will rewrite the pseudo code part so it can subsequently be implemented in the migration.

@louispt1 louispt1 removed their request for review January 29, 2026 14:50
@aaccensi
Copy link
Contributor

Point 1 can already be processed, point 2 I still need to figure out how this should be calculated correctly.

Alright, pseudo-code from point 1 has already been added to the migration. Any further changes are pending on outcome of point 2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Pinned Will never be marked as stale or auto-closed.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants