question

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?

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

./setup

then answer all the questions or

./setup activate eo y dl n

to bypass all prompts.

After install, you should see the ForwardGenInput.py 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 ForwardGenInput.py 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.

[rewrite]

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=

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.)

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

cd /data/GeneratorForward
./setup uninstall dl y

You can also run setup and answer all the prompts:

./setup

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 Venus-generator-start-stop-input-master.zip -d /data
mv Venus-generator-start-stop-input-master GeneratorForward
rm Venus-generator-start-stop-input-master.zip
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.

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.

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.

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.

Yep that worked. I did notice that when the generator starts based on AC load condition the status shows "Running by AC load condition" but the start/stop just says start. Shouldn't the button go to Stop when the Cerbo runs based on AC load condition?

Hello,

I'm not using Guimods, Only ExtTransferSwitch and SetupHelper.

And it seems to be running OK. (switching the input statut from Gen to Grid and vice versa.

i've restored Venus GX 3.01 and all works.
Switching back to 3.10, I can start the genset (manualy) but istopping it, the command is like not executed and there is a message saying, "If all conditions are not meet, the generator will run untill"... (something like that)
I have set the periodic run condition ones every 10 days for 6min

and the minimum running time is set to 6 min too.

Xavier

"If so are you using the Generator digital input or detecting generator running via the AC input?"
No I'm not using the Generator digital input.
The digital input of the (contact loop) generator is given by the transfertswitch to digital input 2 as exttransferswitch

After the update to 3.10 this is real that I receive a VRM alarm about Genset dig input not detected.

BTW. Now when the Genset is startd, it is correctly detected and the AV input swtich to Genset. But If I want to stop the genset... the command is not operational ! I need to change the relay setup to manualy change his state !!

I've left the genset running thinking OK, it is not running for 6 min (one of the condition).. but either after 10 min it didn't stop !

I'will try to annd an other Dig input as generator, copy of the exttranferswitch input to see if it helps !

Xavier