Bowpay avatar image

Cerbo GX Generator Display Bug - Not detecting digital I/O reading

I got everything finally installed in our larger RV offgrid system.

The Cerbo GX is the central component and is so far working pretty good but running into a generator issue.

When the generator is stopped outside of the Cerbo GX (manually) the Main Generator Screen does not reflect a stopped generator.

If I stop it from the Cerbo it works fine but the I/O digital input doesn't seem to change the outcome of the screen.

The settings screen will show that the generator is started and stopped based on the I/O port. Is this a bug?

This is a really big deal because I have a precision plex system that can activate the generator outside of the cerbo. The open/close contact for I/O generator are being fired but the main screen won't give me the correct into. (not good)

(Generator has been stopped manually on the generator)

cerbo gx
10 |3000 characters needed characters left characters exceeded

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

9 Answers
mvader (Victron Energy) avatar image

Hi @Bowpay

The generator start/stop control feature only uses a relay. Its not using a digital input.

The purpose of being able to select "Generator" as a function for a digital input is merely to see a generator status (on/off) in the device list. Nothing more.

Its limited, but is what it is I'm afraid.

1 comment Share
10 |3000 characters needed characters left characters exceeded

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

So you aren't going to add that to the bug list? If I SSH into the Cerbo can I change that behavior and is the code in a place that requires compilation?

Kevin Windrem avatar image

Here's a new version of the code that connects the generator digital input to the generator control logic. This is a complete redesign that incorporates the code into the existing generator control code.

If a generator digital input is defined, the new startstop code couples that input to the Manual Start such that if the generator is started or stopped externally, the Manual Start state will follow.

Manual Start will not track the digital input if a condition such as low SOC or a test run attempted to start the generator. In this case, if the digital input reports a stopped generator, this is interpreted as an "External Override" and a message is displayed on the Generator Overview page.

The running or stopped state of the input is also displayed on the Generator Overview page. It's text inserted into the icon in the upper left.

The latest addition was to couple running time reported by Venus to the generator digital input. That is, time accumulates only if the input reports the generator is running.

The package can be found here:

If there is no generator digital input defined, the behavior is unaffected from the standard code.

If there is interest, I can look into hooking up the generator AC input as an alternate "running"/"stopped" source.

The previous version discussed in this thread as the "Forwarder" has been decommissioned as I'd hit a brick wall with a separate forwarder service. If you have installed it, please uninstall the package and install this new one.

The changes to are substantial. As such, the stock file needs to be replaced. If the stock file changes in the future, I check the file's content during installation and prevent replacement with the one from this package. I will add file versioning in the future if needed to keep up with Venus software updates.

16 comments Share
10 |3000 characters needed characters left characters exceeded

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

Awesome! I just uninstalled and try to reinstall. Getting a couple of warnings. Wasn't sure what to do...

1591919398539.png (39.3 KiB)

Oh darn. Looks like the two files I need to replace are different between Venus 2.54 and 2.60~26.

I'll need to implement installer versioning to get this new code to install on 2.54. I have 2.54 in the backup slot and will reboot and inspect the files.

Added file versions to installer

You should do a complete uninstall:

cd /data/GeneratorConnector

./setup uninstall

then grab a new repository and install from scratch.

File sets are currently provided for version 2.54 and 2.60~26. I'll do my best to keep the repository up to date.

I have looked into hooking up the generator AC input to this logic, however documentation suggests there aren't any parameters that will provide AC input status for the generator when it is not the selected input. Am I missing something?

Note that I'm running a Multiplus Compact so don't have a second AC input. It's not clear if a Quatro would have additional dBus parameters.

Bowpay avatar image Bowpay Kevin Windrem ·

I asked the question about that. I wanted to see voltage information when the generator was running but the Quattro was not set to AC2 (Generator). I was told that nothing was available to read if the Quaatro is not pointed to that input.

For most marine& rv use we recommend to wire the generator on AC in 1. The priority input.

Bowpay avatar image Bowpay mvader (Victron Energy) ♦♦ ·

Thank you @mvader (Victron Energy) but Victron's logic for RVs is flawed. You have a setting labeled "Do not run generator when AC1 is in use." Because of this setting you always make the Generator priority. When I drive to a place, that has shore power, I plug in and my motorhome should automatically transfer over to shore power and stop using my generator. Shore power is always priority since it provides the most amount of power. You don't offer "Do not run generator when AC2 is in use" therefor you force me to place the generator on AC2. At the end of the day my system works exactly how it should work. When I am not plugged in, AC2 (generator), is always being used. Because there is no power source for AC1 I never have to worry about it. You should change your documentation to support putting generator on AC2 OR make it so that I can choose to not run generator when AC2 is in use. I think the best solution is to just change your documentation. AC1 in my mind should be shore power and always priority. Why would I use my solar system and batteries when I can use shore power?

BTW this is coming from someone that lives in a motorhome fulltime. We also are not stationary. We travel all over the US.

Hi. I understand - but let me explain the limitations:

At the moment, in our Quattros, its by hardware impossible to read “The other AC input”. Also, its in hardware defined that AC in 1 is the priority one.

For a newer generation devices we have this on the whishlist, to make it more flexible. But for now its just a given.

In many yachts & (and I assume) RVs, the reason to have the generator as the priority one is to be able to easily overrule the existing shore and run on the generator on purpose - mainly in situations with so limited shore supply that also PowerAssist can’t help enough.

But indeed, in that configuration the “Stop generator when AC in 1 is in use“ setting then won’t work.

Ofcourse its up to you which input to wire where.

Hope this helps to understand why things are the way they are.

Bowpay avatar image Bowpay mvader (Victron Energy) ♦♦ ·

I guess maybe if you had 3rd world living conditions with dirty power. The most logical way I can see what your describing working would be to handle AC1 and AC2 is if you need 2 sources at the same time. Maybe trying to combine power but I don't think it works that way right? Otherwise I can't imagine the actual use case as your power would continually bounce on and off as it switches between power. In my case I have a 50amp cord and a 30amp cord with a Auto Transformer that steps up voltage on the 30amp side with an auto switch between the 30amp and generator. If I hookup to a 15amp house plug on AC2 then I can limit amperage on the control to 15amps. I just don't understand how anyone in the US would want something different. At the end of they day I believe more people would be using the Quattro the way I describe vs Victron's use case.

The Quattro won't allow 2 sources at the same time right? It's either AC1 or AC2 right?

Show more comments

I looked again at integrating the AC input to the generator's running state. However, there is insufficient information to provide stable and useful "running" display let alone hooking that up to Manual Start, etc.

So unless you have a GX device that has digital inputs, Positive "generator is running" feedback is not possible.

I think was is required is an external device to provide digital inputs for CCGX.

Another enhancement would be to use a digital input to indicate the current source (grid or generator) when the Multi only has one input and external transfer switch is fitted ahead of the Multi.

Kevin Windrem avatar image

I changed the indication inside the generator icon to "Running" reflecting the state of the generator digital input since it is not shown anywhere else. I removed "Run" which reflected the state of the Venus relay. Displaying both was confusing and the status tile reflects that anyway.

I also fixed a bug that occurred if the digital input service disappeared which could occur if the input was redefined to be for some other function.

10 |3000 characters needed characters left characters exceeded

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

Kevin Windrem avatar image

I have made some enhancements to the system that may help with debug.

There are new files in the GitHub. I suggest you download a complete set and reinstall.

I added "Run" to the icon in the Generator Overview page when the Venus relay is closed. (See picture.) This is about as close as I could get to the actual relay and should closely reflect the actual state of the relay. The STATUS messages are based on parameters in the heart of the generator control and while unlikely there could be something down stream that interrupts the relay.

I also fixed a bug in setup that causes the Forwarder to be reactivated with every boot. This isn't harmful - just takes extra time during boot. You need to delete the lines in /data/rc.local that pertain to the Forwarder then run ./setup activate again.

I also optimized the code. The Forwarder was taking about 3% of the CPU and I was able to reduce that to under 1%. I decreased execution time of a section of code taking 0.7 seconds to under 20 mS in a loop that should have run every second.

10 |3000 characters needed characters left characters exceeded

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

Kevin Windrem avatar image

Making progress -- yea!

I'm not sure why your generator didn't start when the SOC or AC load condition occurred. The only control the Forwarder has over the stock generator control is to turn ManualStart on and off which would have not affect on the Venus relay.

The Forwarder will only set ManualStart if all run conditions are clear. The Forwarder will NOT clear ManualStart if any run condition (other than manual start) exists.

Can you check the Venus relay? If it's in the correct state, the problem is not in Venus. But it's possible there's a bug somewhere else in Venus. I haven't been looking at the relay state.

You can disable the Forwarder to check stock Venus logic.


svc -d /service/ForwardGenInput

on the venus command line will terminate the Forwarder.

svc -u /service/ForwardGenInput

(or a reboot) will start up Forwarder again.

The Forwarder log will have entries for it's actions so you can see what it did.

Lines containing "Forwarding" will show when the Forwarder made a change to the ManualStart, which is all it ever does.

Lines containing "Stop Sync Error" will show when the Forwarder sets/clears the condition the GUI uses to display the External override message.

Generator input and startstop dBus service discoveries are also logged.

Sorry about the setup rc.... typo. I updated the setup file yesterday. I fixed it the OPPOSITE way (removed the "er" in both places). This might cause issues later on when you update.

That portion of the script is only responsible for adding recovery code to rc.local to reactivate the Forwarder after a software update.

There is new code in GitHub. Changes are the setup script and a 30 second External override message delay in you suggested. Give it a try.

10 comments Share
10 |3000 characters needed characters left characters exceeded

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

Running into an issue. I can't start the generator at all now using the Cerbo. I tried to reinstall but receiving an error with the latest build. I fixed the permission issue but the last error says "Bad interpreter...". How do I revert everything that was done so that I can verify the gen start/stop?

1591499389137.png (43.6 KiB)

Sorry for the long-winded response. Detailed instructions are intended to help get you running quickly. If you know unix, much of this you will already know.

I wonder if the setup file was corrupted when you downloaded it to the target. The /bin/sh^M suggests it might have been processed as a text file on a Windows machine. (^M is a carriage return which Windows uses at the end of each line but Unix does not.)

If that's the case, you might be able to recover the setup script with:

cd /data/GeneratorForward
tr -d '\r' < setup > temp
mv temp setup
If the script runs now, you may not need to uninstall everything. But I do recommend getting the latest from GitHub and updating what you have.

If you do, wish to uninstall, there's an option for that:
cd /data/GeneratorForward
./setup uninstall dl y

You can also run setup and answer all the prompts:


If the setup script still doesn't run, you could try to copy a fresh copy of it from GitHub, but make sure a Windows machine doesn't treat it as a text file and add carriage returns!

And as a last resort, here's how to completely uninstall manually. You should be able to copy/paste these commands to a command prompt.

svc -d /service/ForwardGenInput
rm /service/ForwardGenInput
rm -rf /data/GeneratorForward
cd /opt/victronenergy/gui/qml
ls -al OverviewGenerator.qml*

make sure you have two files, one ending in .orig

rm OverviewGenerator.qml
mv OverviewGenerator.qml.orig OverviewGenerator.qml

At this point the only thing remaining of the Forwarder is it's log file. If you want that gone too:

rm -rf /var/log/ForwardGenInput

At this point, I'd reboot.

When you are ready to reinstall, I suggest downloading a new copy from the Git repository and copy it to Venus as a zip file. Unzip it to /data/GeneratorForward and run setup again.

cd /data
unzip -d /data
mv Venus-generator-start-stop-input-master GeneratorForward
cd /data/GeneratorForward
./setup activate eo y dl m

BTW, if you are running the setup script on Venus, there's no need to specify the IP address. It's ignored if you specify it. The IP address is only used if you are running setup from a unix host but I don't think PuTTY can do that.

Bowpay avatar image Bowpay Kevin Windrem ·

The latest build is working out great! I did change the delay to 3 seconds instead of 30. 30 was a bit too long. 3 gave it just enough time that it didn't flash the wrong message. The only outstanding issue as of now is the countdown on the running SOC condition and Today's Runtime is still counting up. The problem here is that the generator run hours will be out of sync with the generator. Please tell me we can stop the accounting process? After this issue is resolved I seriously think Victron should include this into the next build. This is what I would expect in the UI.

BTW anyway to make updating an automatic process when a new firmware gets released? Just in case Victron doesn't want to include this fix.

Great!!! Glad things are working.

I've shortened the delay. I though 30 was too long but that's what you'd suggested. It's now 5 just in case.

I changed the "Run" message inside the generator icon. "Running" now indicates the generator is running based on the digital input rather than redundantly reporting what's in the status tile: the generator start/stop relay output.

I also fixed a bug that caused the input to get stuck in a running condition if the physical input went away.

Updates to the GitHub rep:

The Forwarder mechanism and GUI mods will already be reactivated following a software update.

Integrating the generator input with time accumulation will take more work. One big issue is that if there isn't an input to signal the generator is running, time would never count up/down. I also need to provide an indication of why time isn't changing. I'll dig into things a bit but need to consider the scenario where a generator input isn't provided.

Before this becomes a part of the stock code, there's the situation where the AC input is used for signaling that the generator is running rather than using a digital input.Some Venus implementations like the CCGX don't have any! I've looked at this a bit and it's not trivial. A complication here is that not all inverter/chargers have two AC inputs.

More to follow ...

Stopping time accumulation while the generator isn't running will take some effort. I've found the code but need to better understand how it functions before I open the hood and make changes. It'll take time. Not sure when I could have working code to try.

Bowpay avatar image Bowpay Kevin Windrem ·

Maybe Victron can jump in and let us know the easiest route to pull this off? @mvader (Victron Energy)

Some progress. I've got a mechanism to pause running time without canceling the current condition.

But I'm stuck at getting dBus values I need to hook that up to the generator digital input. Any help setting up dbusmonitor or other hooks I can use inside would be greatly appreciated.

Show more comments
Kevin Windrem avatar image

OK, here's a first cut at connecting the generator digital input to manual start/stop

When the generator digital input state changes, the generator's Manual Start state is changed if no conditional run is active. If there is a conditional run active, the generator digital input will not change the Manual Start state and will NOT stop the generator! Instead, a warning message appears on the Overview Generator page:

The work is done in a separate process that interacts at the dBus service level.

You can find the code here, complete with setup script that does all the install work:

Comments please!

9 comments Share
10 |3000 characters needed characters left characters exceeded

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

Didn't work for me. I ran a SOC based on AC load just to get a SOC to fire. After manually stopping it the screen never changed. I did get some errors though when I ran the command on the Cerbo.

1591404855283.png (41.1 KiB)

Messages hint at a permission problem but I did find an error in the setup script. A new on is on the GitHub rep. The error may have caused the script to quit before everything was done.

My testing was from a unix host so I'm not sure what PuTTY might be doing differently. If it doesn't support shared ssh connections that might be part of the problem.

You can run the setup script from the Venus device after you've copied the files over to /data/GeneratorForward.

cd /data/GeneratorForward


then answer all the questions or

./setup activate eo y dl n

to bypass all prompts.

After install, you should see the in the ps list: ps | grep Gen

That's run from the service daemon and there should be a symbolic link at /service/ForwardGenInput that points to /data/GeneratorForward/service

If you've put the files on Venus somewhere else that could be a problem.

If is running, you should see com.victronenergy.generator.Forwarding in dubs-spy

To forward the generator input state to the generator Manual Start, you must have a generator digital input defined and the target generator control must start with com.victronenergy.generator.startstop.

I look at all digital inputs for one with a generator (type == 9).

You should see both of these services in dubs-spy as well.

If you change the generator input state (by starting/stopping the generator), you should see this reflected first in the digital input service in dubs-spy, then move to the .Forwarding service. You'll see that state duplicated there and you should see the ManualStart parameter there change too. Finally, this should be changing /ManualStart in the actual generator service. If all that's happening, AND you have no conditions causing the generator to run, the Generator Overview MANUAL START tile should be changing.

If you do have a run condition, you should see the warning message in the STATUS tile if you manually stop the generator.

The Forwarder log may also turn up clues:

tail /var/log/ForwardGenInput/current | tai64n

(tai64n converts the time stamp to human readable format)

Writing a setup summary line to the log WAS almost the last thing in the script BUT the critical step of creating the symlink to run the Forwarder wouldn't get called!!!!! I think it DID actually happen though according to your console dump.

I moved the logging call to the last step and created the directory structure if it doesn't yet exist. So you should be in a better state after you download the new setup file and run it.

I am slightly concerned about the touch calls. These crate flag files used by the reactivate action but I don't think you are there yet. Again, I wonder if this is something having to do with PuTTY.

setup is split into tow pieces: copying files from host to Venus, then doing all the setup which is run on Venus.

Keep me updated. I'm sure I can get this working for you.


It appears you have placed the Forwarder files in /CustomUpdate. setup uses a hard-coded path and assumes files will be in /data/GeneratorForward. So the script is going to fail if files aren't located there and that directory doesn't exist.

You can either place your files in the expected place or edit the script. Just one place: forwarderDir=

The choice of /data is based on the fact that most other parts of the file system are overwritten when updating Venus software. /data is preserved.

I DID test this package on Venus v 2.54 and works fine.

(The command line I see in your console dump shows you specifying an ip address. If this is run on Venus as it appears, the ip address is not needed but silently ignored.)

Bowpay avatar image Bowpay Kevin Windrem ·

Thank you. Got crazy busy yesterday. I have to head out today but will try to test this out this evening.

No worries. No rush. We'll get this going for you and if it's not what you expected, changes can be made

Bowpay avatar image Bowpay Kevin Windrem ·

I moved the files over to the GeneratorForward and it worked better. There is a nameing issue in the setup file. The file is labeled rc.GeneratorForward but the script is calling for rc.GeneratorForwarder. I changed the file name and it seemed to work. After starting a SOC condition the generator never came on and it now reads this. I think there needs to be a delay of 10-20 seconds before checking to see if the I/O is reporting open or closed.

1591472689924.png (42.7 KiB)

Oh yeah I should mention that my generator is diesel and has 2 timed delayed relays to work with an open/close. Might have to make the delay more like 30 seconds to a minute after thinking about it. If Victron were to use this in their settings then I would highly suggest being able to set the delay in Venus.

Bowpay avatar image Bowpay Kevin Windrem ·

BTW I just tested it using manual run and it worked great! After stopping the message did flash over to the message above "External override...". I think with a delay this will probably not show.

Bowpay avatar image Bowpay Kevin Windrem ·

Crap it was my fault. The last few days have been colder climate and realized that the delay I had set on the delayed relay was too short. Just changed it and now its starting again. That delay might only have to be like 5-10 seconds now. Sorry about that. Still running into that error I posted above with the latest build.

Kevin Windrem avatar image

I have a CCGX not a Venus GX or Cerbo GX and can't test the digital inputs, but I'm willing to help with coding if possible. The generator code is in python source so it's theoretically possible to modify it but need more background on the problem.

dubs-spy shows a generator service but most of it's parameters are read-only so it's hard to change them from there. It appears only the ManualStart parameter can be written and it doesn't affect the main state when a condition (SOC, etc) or run based on time have started the generator.

I'd like to get more details on what happens with the generator digital input. Specifically:

Where do you see that input's state changing?

Is this input making any changes to the generator state?

Have you looked at the generator dbus service to see if any of it's parameters are changing with the generator digital input?

What would you LIKE the generator digital input to do? If this input truly means the generator isn't running, then it seems like Venus should clean up it's internal state, but then what? If a condition that should trigger the generator is still active or becomes active, should a generator restart be attempted? If so, when/how often?

Should the generator input affect only manual run? That is, should the generator digital input going active set Venus as if the operator pressed the manual start button on the GUI?

There are probably lots more questions that need an answer before Venus changes could be made.

Also, it might make sense to combine the three threads currently open.

20 comments Share
10 |3000 characters needed characters left characters exceeded

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

Good news and not so good news:

I discovered hooks to simulate the digital inputs so I can test/debug with my CCGX.

I ran some quick tests and discovered what mvader stated, that this input only displays the generator state on the Device List.

I looked into the "Detect Generator at AC input" and it apparently only generates an error if the generator input is selected and the digital input says the generator isn't running.

So there's much work to be done.

I'd like consensus on what is actually needed. The biggest hurdle is probably to get the generator digital input to interact with conditions that start and stop the generator. Integrating with a manual start/stop "shouldn't" be a huge deal but in my testing, manually stopping the generator from the GUI does NOT stop the generator if a condition such as low SOC requests the generator. As questioned above, what happens if the SOC is low and the generator input signals the generator isn't running? Venus has already activated the generator start/stop relay. So at least, that's an error condition, but how does it get cleared? Does Venus deactivate then reactivate the relay in an attempt to restart the generator????

Feedback please!

Bowpay avatar image Bowpay Kevin Windrem ·

Sorry for the late reply. You have made a lot of good points. For now I am really mainly interested in showing that the generator is running if manually started. The device list will update if the generator is running or not but the main generator screen shows stopped. I need the main generator screen to show running. I am also using SOC for a start and everything else right now is disabled. In the case of a SOC start and a manual shut off occurs I would expect the Cerbo to show disabled generator until the generator is restarted manually. From there the Cerbo would go back to SOC start or whatever rules would be processed.

Basically if the generator is manually stopped then it should 'pause' the cerbo from processing anymore automatic start/stops. Sounds like we would need 3 states for processing the generator Cerbo Manual, Cerbo Auto Rules (SOC, etc), Manual Override Is this possible?

After second thought I am not sure how you would bypass this new 'pause' feature if the digital input gets a closed signal if we try to intercept the call for a regular SOC call. Sounds like a loop or some weird state issue. Hmm... The reason why I need the Cerbo to reflect the started generator is because when I am driving the Motorhome I have a generator button in front. I don't want to exhaust the batteries when we run the A/C so I will kick the generator on. When I go back to the Cerbo the generator start/stop doesn't reflect and now I am out of sync with run time and the ability to kill the generator if I am not by the button or not in the Motorhome.

New Use Case: In the case of a manual shutdown I would expect the cerbo to run back through the SOC rules. If i need to stop it, due to maintenance, then I can always just change the setting in the Cerbo. Hopefully this will make everything much easier.

Could you connect your driver's seat generator start/stop switch to an input on Venus that would do the same thing as the manual start/stop in the GUI?

That would make Venus boss of the generator control so not sure what else would be starting/stopping the generator.

That would also not override runs due to SOC and other conditions though.

Good discussion. We'll get there.

Bowpay avatar image Bowpay Kevin Windrem ·

I can start it using the buttons which are all connected to precision plex or I can manually start the generator at the source. The precision plex knows when I manually start the generator because its also using an input from the generator for run time. The only place I have signal for start and stop is coming from the generator. This is what I am using on the digital input. Using a relay to open and close the contact to position 1 on the digital input.

It would certainly be possible (easy) to add messages to the STATUS tile indicating: "Generator running but should not be" and "Generator not running but should be". The generator relay and all logic within Venus would continue to function as it is.

To do more it does seem we need multiple inputs to Venus.

One possibility is to use a "running" to "not running" transition on the existing generator digital input to "pause" Venus generator control.

I don't think you want to use the transition from not running to running to resume Venus generator control because if there are no conditions that cause the generator to run, the generator would immediately stop.

A second digital input (or a button on the generator overview page) could "resume" Venus generator control.

I did notice that conditions that auto start the generator override the Venus manual stop. That is, you can't stop the generator manually from Venus if an SOC condition is active. So we may need a "pause" button in Venus as well to prevent conditions from automatically start or stop the generator.

Bowpay avatar image Bowpay Kevin Windrem ·

Yes, After more thought it does seem like we need a way to pause the venus instructions otherwise we get into a whole slew of what ifs. I don't think it will be possible though because I can't provide an alternative start signal.

How about this instead...

The SOC start takes precedence. I guess that make sense. If the signal comes through and Venus is in a stop mode then force it into manual start mode. Otherwise do nothing and let venus control it all. Would that work?

Or if a stop is detected and in manual mode then force a stop in Venus. I think that would accomplish most of what I need. As far as the rules I can always go into the Cerbo and deal with it directly. Most of the time we are near fully charged and this scenario probably won't happen as often.

Hi both, nice discussion. Few things I want to add:

1) there is already a function to detect generator running or not; its used for the “failed to start” alarm and works based on the active AC input.

2) if this is purely for the airco, consider to tweak the (available in the gui) rules to make it be started automatically on a large dc or ac current.

3) if you have a phone or tablet on same (wifi) network as cerbo, navigate to http://[ipaddress]/app or try http://venus.local/app - there is a generator control button. See manual, MFD App integration chapter for more details, including what settings to enable. (And I know this is always more work to operate than a button already now on the dashboard).

Show more comments

I think I can synchronize manual start/stop within Venus to the generator digital input:

A transition from running to not running would cancel a manual start but would have no affect on active conditions, so the Venus generator relay would remain closed (and out of sync with reality). The out of sync condition could be reported on the screen.

A transition from not running to running would activate a manual start only if Venus didn't have a condition that would cause the generator to be running (e.g. low SOC).


1) If the SOC is low and caused the generator to run and you stopped the generator outside of Venus, the Venus relay would remain closed and a "generator is really stopped" message would be displayed in the STATUS tile.

2) If you then restarted the generator, the "generator is really stopped" message would disappear. But the manual run state would NOT be change.

3) If Venus had no conditions requiring a generator run (Venus relay open) and you started the generator from some other source, Venus would update it's Manual Run state to running.

4) If a Venus manual run was active and you stopped the generator, Venus would cancel the manual run.

The MANUAL START tile is based on the manual run state: If manual run is active, the tile shows STOP and if manual run is NOT active, the tile shows START.

5) If a timed manual run is active, and the generator digital input transitions to the stopped state, the timed manual run is canceled.


Show more comments
Bowpay avatar image

No answers yet. Thought I figured it out but didn't work..

10 |3000 characters needed characters left characters exceeded

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

Harold avatar image

I don't know if it works, but one of the settings is 'detect Generator input on....'

1 comment Share
10 |3000 characters needed characters left characters exceeded

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

Thanks I tried that but no change in the main display. Seems the generator side of the Cerbo is buggy.