Opportunity loads aircon cloud controlled

[AxelR (Axel)]

Hi @dfaber,

thanks a lot for the great introduction. It helped me a lot to understand how S2 / Opportunity Loads works.

I am trying to use Opportunity Loads to control my air conditioner for cooling/heating.

My setup is as follows:

• I put a Shelly in front of the air conditioner to measure its actual power consumption.
• The air conditioner has to be controlled via a cloud API. It does not have a dry-contact input, and simply disconnecting the power with the Shelly switch is not an option, as the air conditioner needs to shut down properly.
• I set up the S2 resource as described in your introduction.
• The Shelly power measurement is connected to the resource and appears to be correctly received. The power measurement is also shown correctly in the resource debug messages.
• The resource status is:
  CEM connected(opportunity_loads) - NC, OBMC
• The virtual device is visible in the Opportunity Loads priority list.
• I have disabled the NC control type, so the resource is using OPERATION_MODE_BASED_CONTROL.

The resource currently reports the following:

{
  "message_type": "OMBC.Status",
  "active_operation_mode_id": "92fdfd1f-c448-4665-98ac-95ab66db8211",
  "operation_mode_factor": 1
}

The SystemDescription contains two operation modes:

• Off → 0 W
• On → 1000 W on L1

So far, everything seems to be configured correctly, but I am not getting any further.

1. Manual Auto / On / Off control

There is no switch in the main Venus OS switch menu for this virtual device, and therefore I cannot select Off / Auto / On manually.

How is this supposed to be configured?

Ideally, I would like to have the same kind of manual override as the built-in Opportunity Loads devices.

2. Getting the S2 decision into Node-RED

I want to use the result of the Opportunity Loads decision to control the air conditioner through its cloud API.

I was looking at the ModeInstruction / ModeRequest nodes, but I don’t seem to get any output from them.

Am I using the wrong node, or is there a specific configuration required to receive the selected operation mode from the S2 resource?

3. How to test/debug the setup

What is the recommended way to debug an Opportunity Loads setup like this?

I would like to simulate surplus/grid conditions without waiting for actual solar production.

For testing, I created a virtual grid meter in Node-RED and temporarily replaced the real grid meter with it. I can simulate, for example, 1000 W of grid surplus.

Is this a suitable way to test the Opportunity Loads logic, or is there a better way to create a fake surplus / grid condition?

For reference, these are the messages currently coming from my resource:

{
  "message_type": "ResourceManagerDetails",
  "resource_id": "68aa3bba-e6fe-4877-a07a-a50ade27e3ec",
  "name": "Panasonic Ethera",
  "roles": [
    {
      "role": "ENERGY_CONSUMER",
      "commodity": "ELECTRICITY"
    }
  ],
  "manufacturer": "Panasonic Self Made",
  "model": "Ethera",
  "serial_number": "1234",
  "firmware_version": "1.0.0",
  "available_control_types": [
    "OPERATION_MODE_BASED_CONTROL"
  ],
  "provides_forecast": false,
  "provides_power_measurement_types": [
    "ELECTRIC.POWER.L1"
  ],
  "instruction_processing_delay": 0
}

{
  "message_type": "SelectControlType",
  "control_type": "OPERATION_MODE_BASED_CONTROL"
}

{
  "message_type": "OMBC.Status",
  "active_operation_mode_id": "92fdfd1f-c448-4665-98ac-95ab66db8211",
  "operation_mode_factor": 1
}

And the current OMBC.SystemDescription defines:

Off:
  L1 = 0 W
  L2 = 0 W
  L3 = 0 W

On:
  L1 = 1000 W
  L2 = 0 W
  L3 = 0 W

Any advice on the correct way to configure the manual override, receive the OMBC decision in Node-RED, and test the resource would be greatly appreciated.

Thanks!

[nickdb (Nick)]

Moved to a new topic.

You need to have all the components working first:
So you have to be able to feed the actual power used to the resource node.
-You need a virtual switch so you can turn the device on and off.
-You need to be able to retrieve the current state and state changes of that switch (though you can -ignore this and have the node assume instructions work, but this isn’t clean imo).

When this is working you can start building a flow as you need to include the requirements of the S2 node in your flow.

I am doing this with Tuya devices, but if the individual components don’t work independently, they won’t with the S2 nodes.

To give you an idea of what building this looks like, this is a screenshot of my flow, sending power and state information and using functions to convert the payload into/out-of S2 friendly formats.
use debug and inject nodes to get working logic first, then you can build it out from there.

I am considering making a post for a tuya how-to, that will be less confusing than a simple screenshot.

[AxelR (Axel)]

Hi @nickdb ,
thx a lot. That looks quite complicate. Is there any documentation availabel on what is the minimum configuration required? Or a better way to debug what is missing? e.g. you use converters for in/out s2 friendy formats - where can I find them?
What is the best way to simulate gid (or whatever is suitable to tell oportunity loads to witch state)

Thx,
Axel

[nickdb (Nick)]

You need to code this yourself depending on your use case. The nodered implementation enables any device with the right features to be used but you need to be familiar with S2, the structure of the nodes and your own setup.
It can take a fair amount of work.
The resource node automates the integration into venus OS and OL, but you need to build your system around that.

There are examples available, but they may not fit your scenario.

The nodes document the format they use. You should know what format your devices and flow needs, it is straightforward to then convert those as required.

[AxelR (Axel)]

Nice, looks promising now.

So 3 things were required:

• Power measurment
• ModeInstruction to the virtual switch
• ModeConfirmation from the switch to the resource

You have an Enable/Disable OMBC switch in your flow. I would like to assign it to the Auto buton of the virtual switch.
documentaition says to change it with { “payload”: { “command”: “SetControlTypes”, “controlTypes”: [] } } but this requies a cemid, which is only available in the internal debug messages of the resource.
How did you implement this?

Thx

[nickdb (Nick)]

I only have a fully automated override to ensure a couple of things:
Minimum (pumps) runtime irrespective of solar/weather.
A late afternoon cutoff to guarantee battery soc is 100%

This last point is due to a hysteresis when fully charged.
Something that will change with a solarsense in later updates.

Get the basics working, you will then find what behaviour you would like to change.

[AxelR (Axel)]

I understand. so how did you implement these two - what kind of message do you inject to turn off OBMC?

[nickdb (Nick)]

@AxelR I will DM you tomorrow and try get you pointed in the right direction.

[AxelR (Axel)]

Thx a lot. I got it running with:
command: “SetAvailableControlTypes”,
availableControlTypes: [
“NOT_CONTROLABLE”
]

I will check tomorrow if it now really turns on the stuff.
will keep you posted

[nickdb (Nick)]

This setting allows you to disable OMBC control.
Takes a bit of getting used to, let us know how it goes.

[AxelR (Axel)]

I have a second setup: a heat pump with a dry contact, connected to a Shelly 4PM.

• The first Shelly channel (ID 52) is connected to the heat pump and measures its power consumption.

• The second channel (ID 53) is the dry contact and therefore has zero power consumption.

Everything worked with the default settings in the standard Venus UI. However:

• The first channel had to be included in Opportunity Loads in order to provide the power measurement — but it was then disabled as well.

• The second channel actually controls the heat pump, but the UI got pretty confusing by showing both channels.

I have now set it up in Node-RED as well, so there is only one button left in the UI.

Looking forward to seeing if it works tomorrow!

[AxelR (Axel)]

I have now two oportunity load resources.
Sometimes one is missing and the other is doubled in “system-setup → oportunity loads”. sometimes one of them is missting. Node-Red status is CEM connected (oportunity_loads) OMBC. The proper resource states Confirmed:on
There is a significant load increas on the system and everyhting feels a bit slower. One grid meter service takes so long to come up that it is claimed as missing grid meter …

Any Ideas how to solve this?

[nickdb (Nick)]

Historically shelly integrations have been a cause of slowness, but this can also happen with cloud based nodes/calls.

You don’t need to continually send state information.
You need to send it when the flow initialises and then only when the state changes.
Look for where nodes or data is being constantly updated and it does not need to be.
Consider filter nodes or rate limiting nodes to reduce unnecessary comms.

You can also run top in an ssh session while you troubleshoot so you can see if cpu increases or decreases as you enable/disable nodes or make changes.

[AxelR (Axel)]

Okay, it seems stable now.

What status should the resource show once everything is up and running?

My first resource shows “CEM connected (opportunity_loads) OMBC” and is listed in the Victron UI under Opportunity Loads.

The second resource shows “Confirmed Off” and does not appear in the Opportunity Loads list.

Can both resources be part of the same Node-RED flow and belong to the same “Opportunity Loads” group? I noticed that both resources use the same cemId.

It looks like the two resources might be interfering with each other somehow. Could this be related to them sharing the same cemId?

[AxelR (Axel)]

Hi @nickdb ,
my two opportunity loads are somehow mixed up. They either show up duplicate or one is missing.
Function is thererore somehow random aswell …
How can I debug this … protocol looks somehow ok.

Resource	PowerMeasurement	Empfang bestätigt	OMBC.Status sichtbar	Bewertung
Panasonic Ethera			im Ausschnitt	Kommunikation OK, OMBC nicht vollständig nachgewiesen
Wärmepumpe				Sieht vollständig aktiv aus

Thx

[nickdb (Nick)]

Did you copy and post s2 nodes or create them from scratch?
You will need to paste the json to check.

[AxelR (Axel)]

Hi @nickdb ,
I remember that I created the resouce from scratch and only copied the mode translation nodes.
Anyway - very good tip I created both resources from scratch and now it looks snooth: Nothing missing, no duplicates, all behaves as expected.

So there must have been a mixup in the resource nodes - even I checked them 10x to be 100% identic

I’ll post an update if it works - and a sampel flow as an example for your library.
Maybe this would be a nice improvemnt for the next release … the rousource to talk out of the box with the virtual switch: No message translations needed, that’s something most people would help … not?

Thx a lot for your help

[AxelR (Axel)]

Hi @nickdb

I have changed the resource owned virtual device from typw “ac load” to “heat pump”.
Then everything stoped working and did not turn itself on anymore.

What is the difference of both types - I expected that it will simply change the category in the energy report and the rest is the same?

thx

[ptrenz (Philipp Trenz)]

@AxelR You discovered a gap in GX Opportunity Loads: Although the S2 palette does alrady support the heatpump role, GX Opportunity Loads as of v3.80 does not yet. We’ll close that gap in a future release.