Venus OS v3.70~61 available for public testing

You can’t. It’s in the release notes of an earlier 3.70beta.

Would be interesting to know when the remaining types like heat pump and evcharger will be supported. @mpvader other than 75CT I think I have not seen support for shelly or virtual devices yet. Is there any update on the use of Heatpump in general (vrm forecast wise) ? Winter is coming. Heatpump is the second biggest consumer after the evcharger.

Also, any chance the new shelly support will in future work with a password on the device ?

1 Like

Since 3.70 when you go in to see the history from the smartsolar you used to could see the last 31 days, now you can only see today and yesterday.

Is that something that will be corrected in the near future or?

For me it seems the readings for the Shelly Pro 3EM under devices in Venus are showing the Apparent Power VA values instead of the Active Power W values. @mpvader any chance you can register this as a bug and ask the devs to swap the readings please ? They are relatively closing during normal operation but as you can see they are way off during standby due to pf.

This is for the new/native beta integration. No custom python scripts or attempt to configure web sockets.

I noticed a similar situation with the em540 as grid meter and wonder whether this is related.
I can’t find any menus to read apparent power vs active power though, is that a Shelly feature not available in the em540?

Signalk does not work after enabling the switch in settings.

IS this a known issue? Does anybody else have signalk running?

I have ekranoGX with no modifications.

Thanks.

Not sure if readings from the EM540 are the same. For me it’s any easy fix and I don’t think Victron uses Apparent Power for anything if the device is just an acload ??? So I followed documentation and changed:

/opt/victronenergy/dbus-shelly/energymeter.py:

s[em_prefix + ‘Power’] = status_json[f"{p}_aprt_power"] > s[em_prefix + ‘Power’] = status_json[f"{p}_act_power"]

I hope this does not break anything, I’d rather have the devs change this :slight_smile:

Hi, I tried and it works well here. Make sure you open Signal-K on the right URL, which when local to the system is http://venus.local:3000/, or http://[ip address here]:3000/

Also nothing has changed recently. (and to those asking: yes I’m aware we need to update the version to a newer one! Apologies that that is taking a while)

1 Like

Hi,

It seems you are using the our “legacy Shelly” support, which was never officially announced, supported and documented.

We won’t be adding any further improvements for that, since we’ve started rolling out the new version; which is configured from within the GX (uses mdns to find the Shelly, and then the GX connects to the Shelly). Its on the roadmap to add a user option to add Shelly’s by entering an ip address in the gx.

For now, I think these are your options:

  1. put that shelly in the same vlan, so its findable by mDNS.
  2. use another meter.
1 Like

Hello,

Thanks for the reply. I am very familiar with the correct URL to be using, and even when I click on the link in the remote console the signalk site does not load.

The remote console and node red are working fine.

I also just downgraded to v3.66 and signalk will not start or be accessible there either. I have disabled and re-enable signalk a few times and rebooted the Ekrano GX.

It seems that signalk is broken on my system. How can I reinstall it? There is no data that I need this is first time using it.

I do not have ssh access to the device so cant confirm if the service is starting and failing or whatever. I prefer to keep the system unmodified.

Alex

I have opened a new topic for this issue:

Hi @mpvader

We’ve had a nodered flow running for ~6 months now to update the fixed prices on a daily basis. Over the past couple days we’ve seen the following error when attempting to send the new buyPriceSchedule:

We haven’t touched the flow in a while… is this expected on the new beta? Or do we need to update anything on our end? We’re on 3.70~45

There have been breaking VRM-API changes, see change log and keep in mind it is quite well possible that change log not to be complete.

See also the link in this post: Venus OS v3.70~45 available for public testing - #76 by UpCycleElectric

Thanks… I just reverted to 3.66, and everything works fine. I’m not seeing a changelog entry related to patching DESS settings. I wonder if there’s a bug in the VRM API node? Seems 3.66 an 3.70~45 use the same API endpoints.

EDIT: Seems I’m not the only one seeing the 422 error: [BUG] Verbose mode does not provide verbose log data · Issue #37 · dirkjanfaber/victron-vrm-api · GitHub

I tried the Shelly support, and mDNS does find about half of my Shelly units. It does find 1PM Mini models. All PM Mini models are missing from the listing. All are in the same VLAN as Cerbo. Running ~45

Thanks for your reply. I’ll live with the problem until the manual adding of IP is released - mostly since I cant judge the consequences of not being able to select AC Input or AC Output - I’e what does that setting influence?

/Kaj

1 Like

v3.70~46 = SignalK 2.14.4

Meanwhile SignalK:
Latest
v2.17.2

4 posts were split to a new topic: V3.70-beta single unit on three phase system peak shaving question

@4000000068ee16a7059928ac 14 Oct 11:23:41 - [error] [victron-input-gridmeter:b00bb1ee5e19c4dc] TypeError: Cannot read properties of undefined (reading ‘name’)
@4000000068ee16a80d75b784 14 Oct 11:23:42 - [info] Started flows
@4000000068ee16aa1df739fc 14 Oct 11:23:44 - [info] [mqtt-broker:CerboGx] Connected to broker: mqtt://venus.local:1883
@4000000068ee218b01c04f94 (node:29726) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 connect listeners added to [Socket]. MaxListeners is 10. Use emitter.setMaxListeners() to increase limit
@4000000068ee218b01cddc54 (node:29726) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 ui-event listeners added to [Socket]. MaxListeners is 10. Use emitter.setMaxListeners() to increase limit
@4000000068ee23cd11fbbca4 14 Oct 12:19:47 - [info] Stopping flows

There is a fault in the Node Gridmeter & this results in a Memory Leak warning.

Latest Beta version actif.

This probably has to do with the fact that the grid meter is broadcasting so many updates per second on the dbus (when in grid meter mode) and reading all of them is a bit heavy on the system. There are some plans to reduce the dbus update frequency, which will help in the long run, but not right now.

Also not too sure what can be done on het input-gridmeter side to mitigate this. But made input-gridmeter update frequency · Issue #314 · victronenergy/node-red-contrib-victron · GitHub in order to check.

@dfaber Replaced the node with Mqtt and since then no faults any more but the update is slower (but still ok)

Are you sure there is no fault in the code ? [error] [victron-input-gridmeter:b00bb1ee5e19c4dc] TypeError: Cannot read properties of undefined (reading ‘name’) Looks like he doesn’t find ‘name’ or ‘name’ is not declared.

Strange but I had also often this fault

@4000000068ee2d491bd2bbec 14 Oct 13:00:15 - [warn] [victron-modbus:EVCS Status] Modbus exception 10: Unknown error
@4000000068ee2d491c4b5304 Service com.victronenergy.evcharger/40 not found in cache. Publish may fail.
@4000000068ee2d491cad2214 Service com.victronenergy.evcharger/40 not found in cache. Publish may fail.
@4000000068ee2d491cf7cf44 Service com.victronenergy.evcharger/40 not found in cache. Publish may fail.
@4000000068ee2d491d340554 Service com.victronenergy.evcharger/40 not found in cache. Publish may fail.

Since the node Gridmeter is not anymore in the flows this doesn’t happen anymore. But will follow up this last one.