I just tried searching the manual relevant my dow stairs heating pump (the most annoying one) who is a CS- NE12JKE and followed that as best i could but it didn’t work for some reason.
Unless i found the wrong manual this should be the procedure:
4. REMOTE CONTROL RECEIVING SOUND OFF/ON MODE
The Remote Control Receiving Sound OFF/ON Mode will be activated if the Auto OFF/ON button is pressed continuously for more than 16 seconds (4 "beep" sounds will occur at 16th seconds to identify the Remote Control Receiving Sound Off/On Mode is in standby condition) and press "AC Reset" button at remote control.
Press "Auto OFF/ON button" to toggle remote control receiving sound.
- Short "beep": Turn OFF remote control receiving sound.
- Long "beep": Turn ON remote control receiving sound.
After Auto OFF/ON Button is pressed, the 20 seconds counter for Remote Control Receiving Sound OFF/ON Mode is restarted.
I get it to do the 4 beeps, and i press the “AC Reset” button on my remote. But next time i press Auto OFF/ON nothing happens. So I got no idea what i’m doing wrong.
And it still beeps like a asshole
EDIT:
Made it work! I had to unplug the sensibo unit first so it didn’t abort what i was trying to do with it’s constant command spamming. Now it’s all silent, finally Thx for leading me down that route Frode, i didn’t think it was possible to turn it of from the service menu:v:
Great that it works now.
Then, over to the second issue. It’s not supposed to spam the AC with the same temperature all the time. If the old temperature was the same as last time then it should not even send the signal… Thus, can you check the log if it still tries to send the signal if you send the value 23 instead of 23.5?
If so, then I should probably make a note of that for the sensibo device. The problem is that the Sensibo driver works for multiple different brands so even if it reports that it can set a decimal value it may not be the case for everyone…
So it’s probably good if we manage to remove the spamming of the Sensibo device because it’s also wasting your wireless bandwidth. (not much though, but nevertheless…)
EDIT: Actually, on closer look , Sensibo devices have a temperature step of 1, so it shouldn’t be possible with decimal delta temperatures, so this is a bug.
I would live to know when the app is going to start charging the car. I have set a «charge the cheapest 30kW befordre 07.00», bit would love to be able to get a Feedback of when that is.
(This would also work as an assurance that charging actuslly IS scheduled)
Hi @Ivar_Ekseth. The car-charging functionality of the app is an area I do want to improve in the future as it may not be the most user-friendly at the moment, I apologize for that. It is important that you follow the following steps to enable the charging:
Depending on your kind of charger the procedure may differ.
If you have an Easee charger, you must add this as a controllable device by the app.
If you have more than one charger then special handling may be required. I assume that you have one charger for now and skip this step.
If you do not have an Easee charger then you need to do the controlling logic with flows. I’ll explain if this is the case.
Once the Easee charger has been added as a controllable device it will no longer charge when you plug in the car. It will from now on only charge when you create a charge schedule.
The charging schedule is started with a flow card as you did.
Once a charging schedule has been created you can preview it in the app settings under “Advanced” → “Car chargers”. Note that when you use the kWh flow as you used then the schedule may change during charging depending on how well the delivered energy fits with the prediction.
In most cases the charging should deliver energy as intended within the charging plan, but for some cars, you may have to use the override function in order to make the charging play along. I’ll get back to this in case the normal flow of operation doesn’t work for you.
Thanks Frode!
I think the Charge-schedule preview is the value i am looking for, so it would be nice if this was exposed as a tag-value.
As for the Easee as a controllable device: I previously had Tibber as the controller in Easee-app(outside Homey). After cutting tibber i had them removed from The Easee-app(outside Homey). After this i readded the Easee to Homey, and enabled it in Piggy. However there is no longer any “controller” listed in the Easee-app(outside Homey). And charging starts immediately after connecting car to charger.
Piggy only communicates with the Easee app in Homey; As long as your device is controllable by the Easee app for Homey it is controllable by the Piggy app. When I said it had to be marked as a controllable device I meant from the Piggy setup under “Devices” → “Controllable Devices”
Operator/Operatør – A setting ON your charger, changable in the Easee-app or https://Easee.cloud
If I understand you correctly, you have removed Tibber as Operator of your Easee charger, and now you have Operator set to “none” or “ingen”? Piggy is controlling the charger through the Easee-integration, but charging starts automatically. Have you checked if it stops automatically within 2 minutes?
Could you try setting “Easee” as Operator and see if this changes anything?
Considering testing a different price point strategy. I’m using daily average now, but I’m thinking it might be smart to switch to another calculation using the previous X and next Y hours function.
I use 72 hours into the past, 0 into the future.
Though, not sure if I should reduce it because the effect of long smoothing periods is that you might get entire days marked as expensive when the prices are going up. Of course you save a lot when prices are going up then but it may get more uncomfortable than you like. If you prefer comfort over savings then you should probably keep it at 0,0.
Before I made this app I used a formula that multiplied the comparison point with a reduction factor for every expensive hour without a cheap hour in between. This made sure that you would always get heating enabled every now and then so not entire days are marked with expensive. The downside is that you will get some expensive hours marked as cheap, but it may be a better compromise between savings and comport.
Another multiplier I had in the earlier days was one that accounted for the derivative of the price, so if the future price was rising then it increased the probability to get a cheap hour before the rise. Similar the other way around: if the future prices was dropping the likelihood of getting an expensive hour would increase in order to delay the heating until it’s cheaper.
I just wanted to keep it simple when I made the app, which is why I removed them. Please let me know if you want me to add any of these again.
Well, my thought was to be able to avoid a situation, where the price point is set to expensive to soon.
Often the price rices gradually before it hits a top. And that means that if my temperatures are adjusted down in the “first” expensive hour of a curve, it’s even more expensive when my heating devices has to kick in a few hours later to maintain the lower temperature set. There is a limit to how long my heated floors are able to “store” the heat. So it would be better to maintain higher temperatures into the ricing price hours and then drop them closer to the price top so that no electricity is used in the actual highest hours.
Of course, this is not always the case, and I guess there is no formula that would be perfect, since the price pattern changes every day.
(Perhaps you could implement ChatGPT to plan the heating schedule every day )
Hehe, if you can suggest a good query that takes a json-distribution of future prices as input and json-distribution of future pricepoints as output I might consider to integrate my two apps closer by creating flows for it if you fancy using it.
I’m trying to figure out if I found a bug or do not understand the “Override device” function properly.
I use the flow below, to set the childrens rooms to override during the day with fixed 14 degrees since the doors are normally open and get heat from the heating pump.
But during the night, the door is closed and I want piggy bank to control the devices.
However, when I have "more than 2 device set to “override”. In the overview page of “overrided devices”, it will only display 1 - even if I set 2 devices to override.
So… Is only 1 overrided? Or is only 1 dispalyed in the overview, but the devices itself are really overrided?
Mine show 2 Mill ovens as overridden when I manually right click and run 2 override cards (test from here). What happens if you try the same? Will both or just one show up then?
Your flow makes Homey having to set the temperature on a Mill oven AND enable override at the exact same time. If it works when you manually override by right clicking, try changing your flow to execute in series instead of using delays.
Check out “Tidsstyring” under the Advanced tab. Very soon you can get rid of flows like this, given your trigger is controlled by time of the hour of course
I am using 6 hours into the past and 12 into the future. My thought is that this is a realistic horizon of heat storage capability. However, I noticed today that nearly all day is set to expensive, and if you see the image i posted here, the gliding average is well below the actual price at all times. As mentioned, 6 hours into the past, and 12 into the future should mean that the gliding average should be higher than it is now?
The override page only shows the state as it was when you entered the setup (I think). Could it be that you entered the setup within the 10 sec delay waiting for the Ellinor heater to change?
Another thing I have noticed with these flows with selectable devices is that if you remove a device from homey and re-add it then the old flow will still list and link to the previous linked device. This might cause some pain as it would appear that the flow could be working but it is not. If this is the case you can remove the flowcard for the non-functional override and create it again.
Yeah, this option will solve the same situation, but the preview you refer to is only visible in the test-version. Continued development of this feature has been on hold for a while though because I had a request to add support for the power-tariff that was introduced in Belgium recently, so I have been working on a major rewrite to get this supported. This has taken a bit more time than expected, so the time-control feature has been pushed a little bit into the future but it will be finalized in the not too distant future.
The gliding average should for every hour be weighted as follows for your case:
Thus, you should have been seeing a large jump up 18:00 in your graph due to the price increase at 09:00. I cannot see this in your graph, which is suspicious. This can be caused by a few things:
The price fetching for next day failed and could not be retrieved before later in the evening. In this case, when the +12 hour price is not known it will use the 23:00 price in the formula above instead as a replacement for the price_12_hour_into_the_future variable. I have an open ticket to improve the reliability of future prices here, but I have not had time to fix it yet, but it is planned.
I can not see a bigger jump in gliding_average in your graph before 00:00, which is 6 hours before the actual jump, which could mean that the future and past values has been mixed? If so, this would be a bug.
Can you see on your raw-data for your graph and check how well it fit with the formula above to identify if any of these are the case?
Hi all – first I must admit that I have spend some hours trying to figure out my best option for controlling the usage of power with regards of “spotpris” after the change from Tibber – when they altered the price model. I find Piggy Bank to fulfil most of my needs – up to when my solarpanels delivers more power than I use.
My setup; Advanced Flows, Solkonto, Tibber Puls, Easee, Høiax Connected, Solar Panel (Growatt) + heating via Mill WiFi and TRM3 Heatit Controls.
Any suggestions on a flow/ function to controlling usage when positive solar panel production?
Change the operating mode of piggy bank - I can deactivate how to make it back to normal?
Change Sparegris prispunkt til Grisebillig – how to make it back to normal?
Thx for leading me down that route Frode, i didn’t think it was possible to turn it of from the service menu:v:
)
