# What Controller to use to switch a digital output channel at a given date/time (optional: depending on feed to grid)? **URL:** \ **Category:** Uncategorized\ **Created:** [July 9, 2026, 1:16pm UTC](https://community.openems.io/t/what-controller-to-use-to-switch-a-digital-output-channel-at-a-given-date-time-optional-depending-on-feed-to-grid/10893 "2026-07-09T13:16:02Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![sjjh](https://community.openems.io/user_avatar/community.openems.io/sjjh/32/2296_2.png) [@sjjh](https://community.openems.io/u/sjjh)\ **Post date:** [July 9, 2026, 1:16pm UTC](https://community.openems.io/t/what-controller-to-use-to-switch-a-digital-output-channel-at-a-given-date-time-optional-depending-on-feed-to-grid/10893/1 "2026-07-09T13:16:03Z")
A device (a heating element) should be powered up for a given time frame\[1\] once a week. Which controller would be best suited for this usecase? I had a look at the [Controller IO Heating Element](https://openems.github.io/openems.io/openems/latest/edge/controller.d/io.openems.edge.controller.io.heatingelement.html) but it seems a bit over-complicated for our use case. Is there a better suited controller? Additionally, I’m not sure how to provide the date parameter in `JSCalender` format to the _Controller IO Heating Element_. I found following example in [ControllerHeatingElementImplTest9.java](https://github.com/OpenEMS/openems/blob/develop/io.openems.edge.controller.io.heatingelement/test/io/openems/edge/controller/io/heatingelement/ControllerHeatingElementImplTest9.java): ```auto { "@type":"Task", "start":"08:00:00", "duration": "PT12H", "recurrenceRules":[ { "frequency":"daily" } ], "openems.io:payload": { "sessionEnergy": 12000 } } ``` But to be honest, I’m not sure how to translate that to the input field in the controller set-up screen of the UI. Would `{ "frequency":"weekly" }` be enough for the _Scheduler_ input field? _Note:_ A more advanced controller algorithm would make use of a time frame with feed to grid within the upcoming seven days and/or a time frame with the cheapest price to optimize the energy usage/price. Main guardrail is running the device at least every seven days. * * * 1. Actually, until a given temperature is reached, but right now we don’t have access to the temperature sensor, thus we will empirically analyze the time needed to heat up. ---
**Author:** ![alex.belke](https://community.openems.io/letter_avatar_proxy/v4/letter/a/49beb7/32.png) [@alex.belke](https://community.openems.io/u/alex.belke)\ **Post date:** [July 14, 2026, 12:17pm UTC](https://community.openems.io/t/what-controller-to-use-to-switch-a-digital-output-channel-at-a-given-date-time-optional-depending-on-feed-to-grid/10893/2 "2026-07-14T12:17:26Z")
Hi sjjh, I would say if you want the heating element to work once or twice a week, you can create a task something like this: `[{` `"@type": "Task",` `"uid": "8749fd94-ef00-49f9-8e09-524477675ca6",` `"updated": "2026-07-14T12:12:20.556727421Z",` `"start": "2026-07-14T20:00:00",` `"duration": "PT1H",` `"recurrenceRules": [{` `"frequency": "weekly",` `"byDay": ["mo", "we"]` `}],` “[openems.io](http://openems.io):payload”: { “sessionEnergy”: 12000} }] What kind of heating element it is? ---
**Author:** ![sjjh](https://community.openems.io/user_avatar/community.openems.io/sjjh/32/2296_2.png) [@sjjh](https://community.openems.io/u/sjjh)\ **Post date:** [July 14, 2026, 8:47pm UTC](https://community.openems.io/t/what-controller-to-use-to-switch-a-digital-output-channel-at-a-given-date-time-optional-depending-on-feed-to-grid/10893/3 "2026-07-14T20:47:15Z")
Thanks for the example @alex.belke! So, the mentioned controller [Controller IO Heating Element](https://openems.github.io/openems.io/openems/latest/edge/controller.d/io.openems.edge.controller.io.heatingelement.html) is the best one?! Just to get it right for me: ```auto "uid": "8749fd94-ef00-49f9-8e09-524477675ca6", "updated": "2026-07-14T12:12:20.556727421Z", ``` is missing in the test-example. Can I assume that these are optional fields? `"start": "2026-07-14T20:00:00",` is only using a time value in the test-example. Can I assume that a time value is enough? Is it correct, that this is the time of the day when the device would start heating? `"duration": "PT1H",` I have no idea what the `PT` is meant for, but I assume that the `1H` means to turn it on for one hour, correct? `“sessionEnergy”: 12000` What does this value mean? What do I need it for? Can I somewhere find a specification/example of the `JSCalender` format that is a little more concise than the 100 pages IETF RFC? _Edit:_ I did find [JSCalendar](https://www.iana.org/assignments/jscalendar/jscalendar.xhtml) that let me locate keywords in the RFC (and `uid` and `updated` seem to be mandatory). Still maybe an online generator with some examples would be a nice tool. 🙂 > [@alex.belke](#): > > What kind of heating element it is? It’s a three phase heating element (if this is the kind info you were referring to). It’s a _Trias - JSP1 078120I3 2KH1_ by [Vulvanic-Triatherm GmbH](https://www.triatherm.de/produkte/einschraubheizk%C3%B6rper/). ![type_plate](https://community.openems.io/uploads/default/original/2X/4/47a300dcb994f27886218112dcd7156f28f6a3af.jpeg) Would below screenshot show a sensible configuration for the controller component (some of the fields seem not necessary to me)? ![controller](https://community.openems.io/uploads/default/original/2X/f/f451b656fb4e66f679b0ff7dcc1722654118b673.png) Scheduler: ```auto [{ "@type":"Task", "start":"02:00:00", "duration": "PT2H", "recurrenceRules":[ { "frequency":"weekly", "byDay":" ["su"] } ], "openems.io:payload": { "sessionEnergy": 12000 } }] ``` ---
**Author:** ![alex.belke](https://community.openems.io/letter_avatar_proxy/v4/letter/a/49beb7/32.png) [@alex.belke](https://community.openems.io/u/alex.belke)\ **Post date:** [July 15, 2026, 8:22am UTC](https://community.openems.io/t/what-controller-to-use-to-switch-a-digital-output-channel-at-a-given-date-time-optional-depending-on-feed-to-grid/10893/4 "2026-07-15T08:22:12Z")
Why did I ask for type of heating element? 😀 We have two heating elements that are already implemented. [Askoma Heating Element](https://openems.github.io/openems.io/openems/latest/edge/device_service.d/io.openems.edge.heat.askoma.html) and [my-PV Heating element](https://openems.github.io/openems.io/openems/latest/edge/controller.d/io.openems.edge.controller.io.heatingelement.html) I thought if your heating element is one of those. Then they would be better option to take. For all others I would say [Controller IO Heating Element](https://openems.github.io/openems.io/openems/latest/edge/controller.d/io.openems.edge.controller.io.heatingelement.html) is the way to go. Regarding **uuid** and **updated** fields, I thinks they could be optional. You can try it out. Just in case If you would use **uuid** , it must be unique. **PT** means ‘Period of Time’. The time format is standardized according to [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601). For example PT1H30M15S - 1 hour 30 minutes 15 seconds. > `“sessionEnergy”: 12000` > What does this value mean? What do I need it for? **sessionEnergy** is how much energy has already been produced in the current heating session (Wh). In **WorkMode.ENERGY** , the controller compares this value with the target ( **energyLimit** ) to see how much is still missing. It uses that to decide if the target is already reached (DONE), still possible, or UNREACHABLE. It also calculates timeToForceHeat — the latest time forced heating must start to still reach the target before end time. So in short: **sessionEnergy** and **timeToForceHeat** are only relevant for energy-target control ( **WorkMode.ENERGY** ). > “[openems.io](http://openems.io):payload”: { > “sessionEnergy”: 12000 > } It means “Between 02:00 and 04:00, deliver at least 12 kWh.” **sessionEnergy** in task payload is the energy target in Wh (used in WorkMode.ENERGY), e.g. 12000 = target 12 kWh in that task window. If you only want “run for 2h”, use WorkMode.TIME in config; this is usually simpler. In TIME mode, sessionEnergy is currently still required by payload schema, but control logic does not use it (0 is fine). Schedule does not override Mode; Mode (AUTOMATIC/MANUAL\_\*) and WorkMode are taken from config. Schedule mainly defines when the controller is active (within automatic operation). ---
**Author:** ![sjjh](https://community.openems.io/user_avatar/community.openems.io/sjjh/32/2296_2.png) [@sjjh](https://community.openems.io/u/sjjh)\ **Post date:** [July 23, 2026, 2:18pm UTC](https://community.openems.io/t/what-controller-to-use-to-switch-a-digital-output-channel-at-a-given-date-time-optional-depending-on-feed-to-grid/10893/5 "2026-07-23T14:18:09Z")
Just a quick heads up: It was now decided that using the time frames with surplus or at least lower electricity prices have priority. As we couldn’t trick OpenEMS in handling the heating element as a EVCS (and using a feed to grid depending controller), we are back to using the Single Threshold Controller with the `_sum/GridBuyPrice` as value. Ensuring to run the heating element once a week is currently done manually.