I still have version 0.19.40, so I am not sure. However, I will investigate tomorrow if the problem I experienced still happens when changing priorities etc.
I believe it was random in my case. I didnât enter the settings until I noticed the error. Didnât change anything, just checked if anything had changed on itâs own.
I rarely touch the settings.
By I am on the test-track, so I usually double check my settings when I notice that the app has updated, just in case.
I tried now to do a little test. At 13:15 today, I enter the âmodes and prioritiesâ, and changed some priorities. I did nothing to price calculations etc. What happened was that the average price of today changed suddenly (at approx 13:15), so both the low and high levels changes, as well as the current price. The average price of today should be constant through the day⌠At 14:00 it changed back to the correct level, and so did the limits. However, the price point is now at âcheapâ, (although the correct is âexpensiveâ). Maybe it compares with the âtodays averageâ from previous hour (which was too high)? Anyway, this is the same I saw before the weekend. When I change priorities, the price seems to behave strangely.
I am still on 0.19.40.
And a screenshot from the insights-app, at approx. 14:03. As you can see, the price point is at Billig, although the limits should call for âDyrtâ.
Update 15:03: Now the price point is back to âDyrtâ, which is the correct.
Thank you for the last report.
I have managed to reproduce the problem now. Apparently I had to run the app in debug mode for more than a day before the problem materialized because it doesnât happen before sufficient state has accumulated. And I wonder if this only happens for those using prices from the Strømregning app. Iâll try to have a fix ready this evening as I now know where to look.
Finally, I have a fix for the buggy Price points, which means that the test-version now contain the following:
Changes in Test version 0.19.43 from Stable version 0.19.40
- Made currency exchange rates latent across app restarts
- Fixed an issue where charging wouldnât start properly
- Added beta-support for
com.arjankranenburg.virtual:virtual_switch - Added support for Toshiba heat pump (note, still waiting for feedback on this so more changes may be required)
- Fixed the invalid Price Point bugs (actually 3 bugs)
- Fixed a minor bug where the cost history was broken (invisible to users still as the cost history cannot be seen in a graph yet)
- Fixed a minor bug where the reliability counters for all devices were reset when entering the setup.
I will be pushing this to Stable in the evening if you can confirm that itâs now working on testing @Torbjorn_Melbye (or @sverf if you want to try out the test version)
Perhaps to soon to tell for sure, but seems to be working.
One thing though.
My settings are +/-10% for expensive/cheap and +/-35% for extreme/dirt cheap.
Calculations for +/-35% seem accurate, but +/-10% doesnât quite add up.
Sounds good.
Remember that the limits for cheap/expensive etc. are clamped based on the minimum amount of cheap/expensive hours in a day, so the % is not the only factor into play.
I have too seen it randomly but very seldom, and then it goes away next time I open the app. It is a known bug, I will probably fix it in the near future. Just ignore it for now if it goes away next time you open the app because then itâs only a display bug.
(normally it should only show if you use the troubleshooting function in the help menu)
1 Like
Iâve also experienced this, and my reasoning so far has been that if the logger is put to anything else than this:
That notification proisland posted will appear.
So even leaving the logger in this state and pressing save:
Will trigger the warning, and disappear when you roll back to âAll informasjonâ and press save.
I mention it in case itâs not a bug, but by design? More info is indeed appearing, even though no unit is chosen
Correction @dooniem, the âAndre Hendelserâ must be set to âBare feilâ (in addition to no selected units in the selector above) for the message to go away. Though, due to the bug mentioned above it will also show up occasionally no matter what you do.
I did an attempt to improve this case here though: Occationally there is a message that extended logging is enabled for no reason ¡ Issue #178 ¡ frodeheg/no.sparegris ¡ GitHub so hopefully, it will be better in the upcoming test version.
Great, seems to work now. Thanks!
By the way, I hope you will continue on this feature, I believe that could be a nice way to adjust setpoints without needing to enter the app controls. 
I will implement time-schedules first, which might remove most use-cases for this and render it less useful. Though, there is an open question in the last comment in that ticket that I would love some feedback on before I proceed.
Is it somewhere we/you could pull loggs on what commands being sent to different componets from Sparegris? Iâve got two Sensibo controlled air/air heating pumps that beeps more or less once every 5-10 seconds because it gets a new command. This only happens when Sparegris is âin controlâ. Itâs driving both me and my wife insane lmao, itâs to the the point where Iâm about to desolder the speaker from the controlboards 
EDIT:
Found out where i could fetch some loggs myself, this canât be the intended behaviour though? 
It sends on signals âall the timeâ:
16:30:35.519: Turn on success
+16:30:43.591: Power keep alive signal.
+16:30:45.529: onPowerProcess: Using: 4495W, Accum: 1265.07 Wh, Limit: 9500 Wh, Reserved: 2500W, Smoothing: 803W
+16:30:45.538: Below power Limit: 10704.902850040631
+16:30:45.551: Can use 10705W more power
+16:30:45.640: attempt changeDeviceState(undefined) for Sensibo 1.etg
+16:30:45.649: finished changeDeviceState() for Sensibo 1.etg - device onoff state was already correct - now checking temp
+16:30:45.707: attempt refreshTemp() for Sensibo 1.etg
+16:30:45.714: Setting Device Sensibo 1.etg.target_temperature = 23.5 | Origin RefreshTemp(23 + 0.5)
+16:30:47.172: finished refreshTemp() for '5063c35e-4355-4348-bce1-e6871cc35ab9 - Success
+16:30:47.180: Turn on success
+16:30:53.399: Power keep alive signal.
+16:30:55.071: Power reported from power meter: 4496
+16:30:57.199: onPowerProcess: Using: 4496W, Accum: 1303.92 Wh, Limit: 9500 Wh, Reserved: 2500W, Smoothing: 794W
+16:30:57.204: Below power Limit: 10727.688790380837
+16:30:57.214: Can use 10728W more power
+16:30:57.258: attempt changeDeviceState(undefined) for Sensibo 1.etg
+16:30:57.317: finished changeDeviceState() for Sensibo 1.etg - device onoff state was already correct - now checking temp
+16:30:57.386: attempt refreshTemp() for Sensibo 1.etg
+16:30:57.394: Setting Device Sensibo 1.etg.target_temperature = 23.5 | Origin RefreshTemp(23 + 0.5)
+16:30:58.924: finished refreshTemp() for '5063c35e-4355-4348-bce1-e6871cc35ab9 - Success
+16:30:58.931: Turn on success
+16:31:3.206: Power keep alive signal.
+16:31:8.966: onPowerProcess: Using: 4496W, Accum: 1303.92 Wh, Limit: 9500 Wh, Reserved: 2500W, Smoothing: 789W
+16:31:8.978: Below power Limit: 10837.42551648404
+16:31:8.979: Can use 10837W more power
+16:31:9.120: attempt changeDeviceState(undefined) for Sensibo 1.etg
+16:31:9.128: finished changeDeviceState() for Sensibo 1.etg - device onoff state was already correct - now checking temp
+16:31:9.180: attempt refreshTemp() for Sensibo 1.etg
+16:31:9.188: Setting Device Sensibo 1.etg.target_temperature = 23.5 | Origin RefreshTemp(23 + 0.5)
+16:31:10.466: finished refreshTemp() for '5063c35e-4355-4348-bce1-e6871cc35ab9 - Success
+16:31:10.472: Turn on success
+16:31:13.014: Power keep alive signal.
+16:31:20.486: onPowerProcess: Using: 4496W, Accum: 1303.92 Wh, Limit: 9500 Wh, Reserved: 2500W, Smoothing: 783W
+16:31:20.493: Below power Limit: 10946.375564346428
+16:31:20.502: Can use 10946W more power
+16:31:20.548: attempt changeDeviceState(undefined) for Sensibo 1.etg
+16:31:20.554: finished changeDeviceState() for Sensibo 1.etg - device onoff state was already correct - now checking temp
+16:31:20.609: attempt refreshTemp() for Sensibo 1.etg
+16:31:20.618: Setting Device Sensibo 1.etg.target_temperature = 23.5 | Origin RefreshTemp(23 + 0.5)
+16:31:22.168: finished refreshTemp() for '5063c35e-4355-4348-bce1-e6871cc35ab9 - Success
+16:31:22.175: Turn on success
+16:31:22.823: Power keep alive signal.
+16:31:25.388: Power reported from power meter: 4501
+16:31:32.218: onPowerProcess: Using: 4501W, Accum: 1341.79 Wh, Limit: 9500 Wh, Reserved: 2500W, Smoothing: 775W
+16:31:32.220: Below power Limit: 10970.507595942088
+16:31:32.222: Can use 10971W more power
+16:31:32.303: attempt changeDeviceState(undefined) for Sensibo 1.etg
+16:31:32.309: finished changeDeviceState() for Sensibo 1.etg - device onoff state was already correct - now checking temp
+16:31:32.380: attempt refreshTemp() for Sensibo 1.etg
+16:31:32.392: Setting Device Sensibo 1.etg.target_temperature = 23.5 | Origin RefreshTemp(23 + 0.5)
+16:31:33.975: finished refreshTemp() for '5063c35e-4355-4348-bce1-e6871cc35ab9 - Success
+16:31:33.985: Turn on success
+16:31:33.994: Power keep alive signal.
+16:31:34.067: onMonitor()
+16:31:34.475: attempt refreshTemp() for Sensibo 1.etg
+16:31:34.481: Setting Device Sensibo 1.etg.target_temperature = 23.5 | Origin RefreshTemp(23 + 0.5)
+16:31:36.132: finished refreshTemp() for '5063c35e-4355-4348-bce1-e6871cc35ab9 - Success
+16:31:36.140: Monitor completed with state: false
+16:31:43.811: Power keep alive signal.
+16:31:44.003: onPowerProcess: Using: 4501W, Accum: 1341.79 Wh, Limit: 9500 Wh, Reserved: 2500W, Smoothing: 769W
+16:31:44.005: Below power Limit: 11084.666566301437
+16:31:44.084: Can use 11085W more power
+16:31:44.157: attempt changeDeviceState(undefined) for Sensibo 1.etg
+16:31:44.166: finished changeDeviceState() for Sensibo 1.etg - device onoff state was already correct - now checking temp
+16:31:44.241: attempt refreshTemp() for Sensibo 1.etg
+16:31:44.246: Setting Device Sensibo 1.etg.target_temperature = 23.5 | Origin RefreshTemp(23 + 0.5)
+16:31:45.872: finished refreshTemp() for '5063c35e-4355-4348-bce1-e6871cc35ab9 - Success
+16:31:45.878: Turn on success
Correct,
You can combat this in two ways:
- On your AC remote you most likely have a button to disable the beeping from the AC (On mine I press Settings, navigate over to Beeping and press set to toggle it.
- If you give the AC the highest priority then it will toggle least. If you give it the lowest priority it will toggle the most.
No settings function on either of them, they are both about 10 year old Panasonicâs. And both are the top two units in the Priority list, so thatâs not the âissueâ.
Guess I have to tear them appart and pull out the soldering iron then 
I do notice something odd in your log though.
As you can see for the onoff state it says
.... device onoff state was already correct - now checking temp
That is correct, so that shouldnât give any beeping.
However, it should have been a similar thing for the the temperature (but it is not)⌠e.g. if the temperature target is already set to 23.5 then it should not try to set it again. Does the temperature not support decimals? If so, does the beeping go away if you set the target to 23?
