The question is raised and technically there shouldn’t be a problem really. More a matter of myself not working for free for Easee Any “cloud” enabled app will be released in the name of the brand.
Replied yesterday to your GitHub ticket. Copying the reply here
The basic charge plan is what is in the app, https://developer.easee.cloud/docs/scheduling#basic-charge-plan.
The description for the start and stop time is the same as for the (new) weekly schedule. I haven’t used it so don’t know if it will stop charging at the stop time for any of the schedule types. Guess we would need to test it out.
Hello!
I am working on advanced flow, and want the flow to start when charging status has changed.
(I connect the car, charging status changes, price is checked and charging starts or pauses based on this).
I am a bit of a noob, but I am suspecting there is something wrong here.
When I add the “when” and “charger status changed to” it won’t let me set an option, and I guess it is supposed to be available here. So as the picture shows, there are no available choises to make, and the flow does not start. I have set my flow to start when the price is changed, but this means charging will start in the period before the price changes - which is ok, but not optimal.
Am I doing something wrong, or is this a bug?
Can observe what you observe, would have to investigate the reason for it.
As a workaround, you can use the same trigger and add a Logic condition in the following step. The status the charger changed to is passed as a token that you can use in the Logic card.
I introduced a new trigger which works as you’d expect. The old trigger is still there with an updated text “Charger status changed”. Please give the test version a go.
I’m implementing some changes to the app (not released yet) and would love to hear some feedback on what you think about it.
New capabilities for;
Turning charging on or off
The app will use the Easee API for toggle charging, so it will automatically choose start/stop or resume/pause based on its internal logic. I believe using the plain toggle should be sufficient. There is a risk that clicking this multiple times in a short time period results in the wrong outcome.
Please remember that we have a pretty complex communication path where the Easee Homey app talks to Easee Cloud which in turn sends commands to the charger. Thus, there is no instant (synchronous) feedback when triggering a command on a charger.
Since Homey maps on/off as actions on the device card the charger device will be “greyed” when in off state. Clicking the device will turn it on/off. I’m not that keen on this logic but there is no easy solution to get out of this “feature”. Will see if I have the time to replace their standard on/off
Turning access on or off
The easiest way to stop a car from charging immediately when connected. If access is off then you can use the turn-on charging capability to start charging.
Setting the dynamic circuit current
The same setting that for instance Tibber is using to control the charge current. Please note that this is circuit current, ie if you have multiple chargers on the same circuit this setting controls all of them.
Visualized with a “slider” which is a little crappy, but don’t see any options.
All of the above are possible to control using actions today. Adding the possibility to control them using capabilities is to make the app more user friendly, and also to allow other apps such as Piggy Bank to control the chargers. Other apps cant run actions, they can only control capabilities. This also applies to mqtt integrations which will be able to control the chargers.
Some positive side effects of the above are;
on/off, lock/unlock are visible in the device timeline
I just thing it sounds great
Mostly like the access options, because I’m disabling charger when not at home.
Thinking of the slider for dynamic current, it will not report current value however, right? This might be tricky, it will be in “percentage” or how the max. value will be defined? Just thinking out loud.
It will report the current value, fetched each 15s from the Easee API, also visible in insights.
The value is in current, ie measured in Ampere (A). My comment about “little crappy” refers to the fact that the Homey UI doesn’t show the unit (A), nor displays the value of the slider. You have to guess the scale, so I understand it is confusing. The max value of the slider is the circuit fuse size as defined in Easee, in my case 20A. The circuit fuse size is displayed under advanced settings on the device in Homey.
Also forgot one thing I also added. Found an endpoint for polling the lifetime energy from the charger to the Easee cloud. I trigger it every 5 mins as it is implemented now and it seems to work. The stats that I log to a database seem to report charging, which is based on the increase of the lifetime energy, for the correct hour. It needs a little more verification but looks promising. Previously the lifetime energy was updated once per hour and for instance, energy used during the hour 02-03 ended up being recorded during hour 03-04 - a 1-hour lag. It broke my nice graphs, and I know some other users have commented on this as well.
@Richard_B@Huub_Van_Vilsteren now I have realized, actually all those flows are broken thanks to this, I thought the conditions are just not appearing due to some internal Homey / cosmetic error…
When I test such flow, I get error :
What is interesting, it’s not caught by Flow Checker - I will ask martijnpoppen if he would be able to catch this, but anyway it looks like all such flows have to be repaired - so it’s information to all users of your app, at least when using version 1.4.7, as it triggered breaking change.
Looked through the code now and understand the problem. Didn’t realize this before, I improved (or so I thought) the code and put all statuses in an enum in the code and used the autocomplete feature for this condition. The argument has the same name, but it caused a change in the id’s in the dropdown
You may be wanting to set the uiQuickAction to false - this should prevent the user from accidentally turning it on/off by clicking the icon, if that was what you was looking for. (I believe you can set it for the standard onoff too if you list it under capabilitiesOptions)
Not sure if I understand this one. Why can’t there be a single onoff? When should I use the one over the other? / when not to?
If you want a slider with numbers you can use the thermostat UI interface instead but then again… it probably will look very odd I agree the Homey UI is very limiting.
The other option would be to use uiComponent “picker” and have all 40 numbers encoded as enum values including the unit.
Speaking about new capabilities, maybe the measure_battery would be useful too?
Yeah, this is kind of annoying. I have experienced this issue myself. The way I solved it was that I marked the old action card with the tag “deprecated” and used a slightly different name for the new action card. This would allow the old action card to still function but they will disappear for new users. The only drawback is that you have some old dangling code that needs to be there to support old users.
I read somewhere that this doesn’t work, that you then have to override the entire onoff capability with flows and all. But I should give it a try.
I use Tibber and then the charger behaves differently. But my understanding is that if you don’t use Tibber the car will start charging every time you connect it. Then you can stop it using the on/off capability. But a better way as I read lately would be to set access to locked. Then you can connect your car and it won’t start charging. Instead, you start the charging via the on/off capability. I have used the toggle API endpoint which will automatically use start/stop or resume/pause.
One option is that your app stops a car from charging if it starts when it shouldn’t. Ie this will happen every time a car is connected to the charger. Then access is unlocked, as is the default.
Or one can set access to locked, and the charger shouldn’t start charging unless you tell it to. Setting access to locked should be a one-time thing, as per docs it shouldn’t change.
Below are the docs from Easee that made me come to this conclusion.
authorizationRequired Set to enable authorization. Charging will not start until the charge point is authorized. API endpoint https://api.easee.cloud/api/chargers/{id}/commands/start_charging
Allows a charger with ‘authorizationRequired’ = true to deliver power. Otherwise it will have no effect
This might be better than the slider actually since it doesn’t show any insight into scale or current value.
Might give this a go when I’m back. Going off for two days with work right now.
Hmmm… Not sure what would be best but I think the users of the app might find it confusing having to both turn on and unlock in order to charge, another option could be to do all this behind the scenes so they only see one onoff, but I won’t be the judge as I don’t even have the charger (yet). So I would be happy no matter what
Please note that you will loose the insights if you make it an enum… so no graphs …but I guess that won’t matter as you probably already get the graphs from the existing capabilities measure_current.p1, measure_current.p2 and measure_current.p3 ?
As explained above, there is no need to use lock/unlock to charge. Up to now lock/unlock access hasn’t been possible via the Homey app. I introduced it in the test version since it is available in the Easee mobile app and I can see that some users would want to use it. I have seen some flows where users used the enable/disable charger to prevent it from charging immediately when a car is connected. This is not a recommended way since it writes to the flash memory in the charger each time.
To be as clear as I can be . If you don’t want the charger to start charging immediately when you connect your car and be forced to use some flow logic stop charging - then you can set access to locked via the Homey app or the Easee mobile app. This you do once, and never touch again.
When you want to start charging you turn the device on, when you want to stop charging you turn the device off.
This is a downer though, I guess few users, if any, will fiddle with the dynamic circuit current manually. Personally, I find it a little interesting to graph how Tibber is adjusting the circuit current and would prefer to keep it available in insights.
Ok, then I misunderstood the concept of the lock. I thought the lock was the authorization, not that it enabled/disabled automatic state changes outside of the app.
Hmm… It may be that you still will be able to make insights for it when it is an enum but then it probably have to be done by manually calling the homey.insights.updateLog(...)
…however, I have not tried to do manual insights so I don’t know if this is the case or not
Any “cloud” enabled app will be released in the name of the brand.
So as the picture shows, there are no available choises to make, and the flow does not start. I have set my flow to start when the price is changed, but this means charging will start in the period before the price changes - which is ok, but not optimal.
I agree the Homey UI is very limiting.
…but I guess that won’t matter as you probably already get the graphs from the existing capabilities measure_current.p1, measure_current.p2 and measure_current.p3 ?