[APP][Pro] Piggy Bank

Does anymore have a good flow on how to use Piggy bank with solar panels? For my part I believe that the most economic for me is to use as much of the solar power mysel, to benefit from grid tariff and VAT.
What I want to achieve is to force my controlled units to run when I have negative consumption.
I have the Price control set to automatisk and reall like that funcrionality. But I would really like to have the option to change the Price mode from normal to dirt cheap when consumption is negative. But I get the error message that I have to set Price management with flows. But I don’t want to do that, I just want to override the automatic pricepoints for a limited period of time. Any suggestions or workarounds on this? When the solar Power is 500 watt I want to run the heating cables, when it is 2000 watt I want to run the hot water tank. Any examples or tips would be appreciated👍🏼

You might be interested in this ticket:

Most of the addons to support solar panels have been implemented. Please comment if you have any input to the rest of the plan/discussion in that ticket.

If you really want something and it’s not too difficult to add support for, I may be able to add it a bit earlier than what the plan suggests.

Hi!
Does this app support two power meters? I have two meters in my house (one for the main house and one for a separate house for renting). That means I also have two Tibber Pulse (HAN-reader).

Not directly, but possible using the Homey CLI, see here for more details: [APP][Pro] Piggy Bank - #886 by frodeheg

1 Like

None of the above was the case for me. No red columns, and I checked the app right after the top of the hour (got alerted about the tarif bust), but no information like the one you describe. I don’t control only one device, but usually it’s only the heater (lowest pri) that needs to be turned of to be able to stay under the desired limit. This time Piggy Bank did absolutely nothing with any of the devices even though I know it knew the usage for the hour.

Hi

The EV charging module suddenly stopped working. Seems like it’s not receiving future price for planning the changing.

Log ID: 2024-03-31T16:41:32.404Z
App version 0.21.14
+16:41:34.033: Electricity price api failed: Cannot read properties of undefined (reading ‘get’)

Edit: Problem only occurs when price type (pristype) is set to external (ekstern). I have the Strømregning app set up.

@Ermo, can you please give me some additional information?

  • Where can you see that the tariff was busted? In the Piggy Bank log, on Elhub, or both places?
  • Which meter reader do you have? Unfortunately, not all brands are as reliable.
  • Which version of Piggy Bank do you have installed?
  • Also, you may be hit by this issue: Ticket #277 it has been fixed in version 0.22.1 being launched on the 6th of April, meanwhile if this is the case, please enter the settings and save the settings, this will make sure that piggy is not trying to control devices that you have deleted outside of piggy.

@ReodorFelgen
The strømregning app only returns prices when it has been configured with spot prices. If you have configured it with fixed prices the price API doesn’t return any prices. I suggest you use the internal price mechanism of Piggy instead for that case.

NOTE for users of the test version:

A big update will be launched night to Saturday the 6th of April.
The update will contain a completely different way of controlling car chargers.
I have kept the old flows for charging in there so nothing is supposed to break, but the update has a lot of risk added due to the rewrite so I urge you to please take notice so you are sure your car is being charged in case anything should fail with the update.

This version is likely to stay as a test version for quite some time so I need your help to report back to me that the following things are working as expected:

  • :white_check_mark: That your old charging flows are still charging the car. (please test this before you delete them because you cannot recreate the old flows once you change to the new charge controller)
  • :x: (waiting for confirmation) That the charge controller is working perfectly in “flow mode”
  • :x: (waiting for confirmation) That the charge controller is working perfectly for “Easee” chargers
  • :x: (waiting for confirmation) That the charge controller is working perfectly for “Zaptec” chargers
  • :x: (waiting for confirmation) That the charge controller is working perfectly for “Tesla” chargers (Please can anyone with a Tesla charger also send me a list of what all the status codes for this device is, because they are invisible to me as it’s a text string and not an enum)
  • :x: (waiting for confirmation) That controlling multiple chargers are working
  • :x: (waiting for confirmation) That the charge token is ok for those who need it.
  • :x: (waiting for confirmation) That charging is working as expected for 220 V
  • :x: (waiting for confirmation) That charging is working as expected for 400 V
  • :x: (waiting for confirmation) That charging is working as expected for 1-phase charging
  • :x: (waiting for confirmation) That charging is working as expected for 3-phase charging
  • :x: (waiting for confirmation) That the historical data is working as it should in the app logs/archive
  • :x: (waiting for confirmation) That the setup process is as easy as I hope it is. If not, then suggest improvements and I’ll try to improve it.
  • :x: (waiting for confirmation) That charging without the need for a flow to start a charging cycle is working (will be added within a few days)
1 Like

@frodeheg


|

  • |
  1. Both. Pretty much consistently identical readings (0,005 difference)
  2. Aidon (with Tibber Pulse)
  3. 0.21.14

tor. 4. apr. 2024 kl. 02:58 skrev Frode Heggelund via Homey Community Forum <notifications@athom.discoursemail.com>:

I dont know if there is any connection, but the app, who has worked perfectly, suddenly stoped updating mode from flows. Ex when leavving the house, my flow puts PB in Away mode, and Day mode when arriving. This change has stoped several times the last two days. Using H23.

@Ermo : Then I am pretty certain this is caused by Ticket #277. Please check if the problem has been resolved with the new test version being released tonight.

@Felix_oslo : It doesn’t sound related since there hasn’t been any updates recently. What happens if you run the flows manually? If it works then it’s probably a HP2023 issue

NOTE!!! (this is now resolved)

I am getting reports that the new version is consuming too much memory and/or CPU so the app is at risk of being killed (most likely if you have HP2019). If you have not tried the test version yet, please do not install the test version before I have resolved these issues.

Version 0.22 is now available for testing

What is new:

  • Added a new device named piggy_charger that will replace the current charge control. From now on the charger device must be installed to control chargers. It will no longer be possible to create the old flows for charge control as these will be deprecated soon. They will still work for a limited time during the transition.
  • Added a video stream to the charging device to give feedback during the setup phase and the charging phase.
  • Added json-token for charging.
  • Added an image-token for the camera interface
  • Added phase and voltage selectors for the main fuse.
  • Minor ui-changes
  • Improvement in reliability for the setup interface.
  • Bugfix: Removed forced crash when an invalid state was detected on MeterUpdate
  • Added support for:
    • com.scinan.api:SASWELL_THERMOSTAT
    • com.tesla.car:battery
    • net.filllip-namron:451275_X
    • no.osoincharge:water-heater
    • no.thermofloor:Z-HAN2

This test version will stay in testing until this checklist has been completed. Please help with feedback.

Note:
If you have issues with this test version, please install the stable version over the test version. There is no difference in settings so it’s completely safe to go back to the stable version.

Resolved issues:

  • :white_check_mark: (improved in 0.22.2) A crash might occur due to high memory usage
  • :white_check_mark: (improved in 0.22.2) A crash might occur due to high CPU usage
  • :white_check_mark: (fixed in 0.22.2) The flow “Stop charging ahead of time” has invalid code in it.
  • :white_check_mark: (fixed in 0.22.2) The image stream of the charge device halted when there was no power prices
  • :white_check_mark: (fixed in 0.22.2) Fixed an error in the bottom two lines of the charge controller images.
  • :white_check_mark: (fixed in 0.22.2) Fixed graph status outside of charge plans
  • :white_check_mark: (fixed in 0.22.2) Charging was not started due to not all settings being updated when a charge controller is added
  • :white_check_mark: (fixed in 0.22.2) device.changePowerInternal is not a function
  • :white_check_mark: (fixed in 0.22.2) Added support for forcing the charger mode on or off according to the mode state and override controls
  • :white_check_mark: (fixed in 0.22.3) The camera image may during initialization show an invalid image for a power supply flow to be created when it is not needed.
  • :white_check_mark: (fixed in 0.22.3) When resetting the charge controller state a timer was not killed so it would cause the timer to crash after a while.
  • :white_check_mark: (fixed in 0.22.3) The charger testing was waiting too much and could seem to hang in the camera interface during the trigger test
  • :white_check_mark: (fixed in 0.22.4) The flow based controller showed the text (timeout is not a property of null)
  • :white_check_mark: (fixed in 0.22.4) May crash on init with the message: “Error: flowtoken_already_exists” if the device is initialized more than once. (e.g. app is disabled and then enabled again)
  • :white_check_mark: (fixed in 0.22.4) When the response test for charging times out it may display (null > 300)
  • :white_check_mark: (fixed in 0.22.5) Uninstalling the device caused ‘Error: device_not_found’ crash.
  • :white_check_mark: (done in 0.22.6) Added feedback that a car needs to be connected in the validation test
  • :white_check_mark: (fixed in 0.22.7) The app doesn’t run the onChargeStart / onChargeEnd commands during testing of chargers
  • :white_check_mark: (fixed in 0.22.7) The app doesn’t run the onChargeStart / onChargeEnd commands during charging
  • :white_check_mark: (fixed in 0.22.7) Firefox and iPhone will cache the first image instead of the latest image, which makes the camera interface look wrong. (changed to a descriptive image for the first image)
  • :white_check_mark: (fixed in 0.22.7) Fixed the video display when having always on mode.
  • :white_check_mark: (fixed in 0.22.7) Price data is not always fetched for the charger device.
  • :white_check_mark: (added in 0.22.7) Changed the waiting images so it’s clearer when to wait and how long.
  • :white_check_mark: (added in 0.22.7) Change the final validation cycle so it doesn’t say failed “on” test. Instead, it should say “Congratulations, all tests passed, you may now turn the controller on.”
  • :white_check_mark: (updated in 0.22.8) The validation procedure no longer shows as failed if the controller is turned off (now it shows informative that you can turn it on)
  • :white_check_mark: (fixed in 0.22.8) The app crashed when removing a charge controller device.
  • :white_check_mark: (fixed in 0.22.8) Fixed validation check for flow charge controllers (didn’t check the state)
  • :white_check_mark: (fixed in 0.22.8) Fixed issue where an uncontrolled charge controller could not be turned off
  • :white_check_mark: (fixed in 0.22.8) When marking a charge controller as not controlled in the app settings the device was not automatically turned off.
  • :white_check_mark: (fixed in 0.22.9) Added workaround for bugs in the iOS Homey app when it comes to refreshing images.
  • :white_check_mark: (fixed in 0.22.10) Voltage and phases selected during pairing is not stored
  • :white_check_mark: (added in 0.22.10) When enabling a charge controller, the old direct control is now disabled
  • :white_check_mark: (added in 0.22.10) If enabling a charge controller in device settings, then give feedback and do not enable it if the validation has not been done.
  • :white_check_mark: (fixed in 0.22.10) Made sure Tesla is not listed as a prioritized device (only the charge controller should be listed at the top)
  • :white_check_mark: (added in 0.22.10) Allow selection of battery update already in the pairing process.
  • :white_check_mark: (added in 0.22.10) Add images to show how to set up flows. The images should be available in the device pairing.
  • :white_check_mark: (added in 0.22.10) Made sure the validation procedure fails if the device is being controlled by other sources (during validation).
  • :white_check_mark: (added in 0.22.11) Added image token for camera interface
  • :white_check_mark: (fixed in 0.22.12) The time zone of the charge controller camera device is displayed incorrectly.
  • :white_check_mark: (fixed in 0.22.12) When using charge x cheapest hours the charging can continue after the charge cycle is complete if more hours was requested than the length of the charge cycle.
  • :white_check_mark: (fixed in 0.22.12) The price graphs for charging were always scaled from 0.
  • :white_check_mark: (fixed in 0.22.12) Fixed status indicator when aborting an already started charging cycle.
  • :white_check_mark: (fixed in 0.22.12) Fixed issue where the last part of the charge plan could disappear from the video interface
  • :white_check_mark: (fixed in 0.22.12) The cost of charging was displayed with a 1000x too high value.
  • :white_check_mark: (fixed in 0.22.12) Toggling of flow devices didn’t work.
  • :white_check_mark: (fixed in 0.22.13) Fixed 2 crash bugs when setting target_power and measure_battery to negative values

Known issues in version 0.22.14 and planned improvements (not published yet):

I`m noticing some chrashes on HP23 as well, but the tooltip says CPU limit.

Also, charge controller does not seem to actually control the chargers. No initial start and no power adjusting. Got this from errorlog: Log ID: 2024-04-06T13:24:48.501Z
App version 0.22.1

+13:24:48.501: Restored state after shutdown. Last power 573.0984833333333 minutes ago: [0,0,0,467431.22410832637] 12947 Sat Apr 06 2024 03:51:42 GMT+0000 (Coordinated Universal Time) 5815.244485555554 0
+16:11:58.666: Error while trying to power down: TypeError: device.changePowerInternal is not a function
+16:12:8.693: Error while trying to power down: TypeError: device.changePowerInternal is not a function
+16:12:38.754: Error while trying to power down: TypeError: device.changePowerInternal is not a function

And this card is not doing it`s thing.

20240406_19530495

Thanks, I will try to fix all the 4 reported issues (listed at the bottom of this post) later tonight.

Nice :blush:

Let me know og there’s anything specific you need me to look out for.

I’m running a setup with two Easee chargers charging three different Tesla’s on 3P-230.
Although usually never more than one at a time since two of them is using the weird open delta charging (28-16-16A) and that makes load balancing between chargers somewhat inefficient.

Regards.
Tom A

I’m not sure if I understand, do you have

  • 2 Easee chargers, one master and one slave charger, which means that only the master charger is controlling the current which then is shared between the two chargers?
  • 3 Teslas where 2 are connected at the same time, but only one is set up to accept charging at the time because the shared fuse between the chargers is kind of useless when one car is capable of taking all the available current by itself?
  • Is this right? And you would want Piggy to do the switching of the cars automatically so they don’t distribute the charging equally between the two cars?

Well the Chargers are set up as master/slave but that doesn’t matter that much. The only thing that actually happens is when you set a dynamic circuit current it will be shared equally between the chargers with no consideration as to the potential consumption except for the charger states “complete”, “standby”, “awaiting authentication” or when dynamic charger current is set to zero, then the full circuit current will be available to a single charger. In short, any state where a car could potentially receive power the circuit current will be distributed as (circuit current/number of chargers) every charger is in reality standalone, master is just commanding max A (observed by leaving dynamic circuit current at max an adjusting dynamic charger current on each)

In essence, yes. But also because the cars for some reason always pulls the highest amperage on L1 which in reality means in terms of total kWh delivered within my desired “Effekttariff” it’s faster charging one at a time.

Well I don´t really need Piggy to handle that since I´m using some flows to automatically detect which car is connected to which charger and assign priority based on both charge level and actual need (same car needs to be fully charged every morning).
From there I just tell Piggy to start that charger, and now also provide the corresponding SOC (actually like this: {{round(Battery level/(Charge limit SoC/100))}})
And when the highest priority completes I just start the other charger.

Might be worth mentioning that I´m not using price control for now :sweat_smile:

Hi,
Is it possible to get a screenshot of the correct flows of setup for the new charge controller? I’m using an Easee charger.

2 Likes

I’ll publish some screenshots when I make version 0.22.2 public.

The memory usage issues was a bit tedious so it took a few days. There are two remaining issues left (listed here), so the test version is still not usable. I will not release the update before this has been fixed.

Meanwhile, please use the stable version (there is no harm in installing the stable version over the test version).

Hi

I can’t find a question mark or text in the app that describes what functionality that you get when you select AlwaysOn on a car charger, will it still adjust the effect available, againt the set effect tarrif?

Asking because some built in scheduling on older cars does not handle that the charger is paused.
Reason for using scheduler is that that’s the only way to set charging limit, and the car is not online.