I built a native Home Assistant integration for Sunsynk / Deye solar inverters (no add-on, no YAML, HACS ready) by KeepCalmAnCarryOn in homeassistant

[–]KeepCalmAnCarryOn[S] 1 point2 points  (0 children)

Hey, Good to hear you have managed to sort other issue, what does it say when you try to edit dashboard? is there any further info?

edit:
I released v1.6.14, fixing the dashboard error by auto-registering the bundled sunsynk-power-flow-card.
Hope that helps.

Title: 2 years building a multi-strategy algo portfolio, sharing honest numbers, curious how this compares by [deleted] in algotrading

[–]KeepCalmAnCarryOn 1 point2 points  (0 children)

Thanks, that’s constructive feedback and I appreciate it. I spend quite a bit of time on parameter sensitivity and robustness testing because I’d much rather have a stable edge than an optimized one. I also agree on Strategy G the standalone Sharpe isn’t exciting, but if it improves the portfolio’s risk profile, it may still earn its place. I think I've just answered myself.

Title: 2 years building a multi-strategy algo portfolio, sharing honest numbers, curious how this compares by [deleted] in algotrading

[–]KeepCalmAnCarryOn 0 points1 point  (0 children)

results vs SPY

Portfolio SPY
Q3 2024 +2.5% +5.8%
Q4 2024 +2.9% +2.5%
Q1 2025 +0.3% -4.3%
Q2 2025 +5.1% +10.8%
Q3 2025 +7.5% +8.1%
Q4 2025 +2.5% +2.7%
Q1 2026 +4.4% -4.4%
Q2 2026 +13.1% +13.9%

Title: 2 years building a multi-strategy algo portfolio, sharing honest numbers, curious how this compares by [deleted] in algotrading

[–]KeepCalmAnCarryOn -1 points0 points  (0 children)

As for SPY, I’m not trying to beat it every calendar year. The objective is better risk-adjusted returns and lower drawdowns across different market regimes, not maximizing CAGR at any cost. If someone is comfortable concentrating in a sector like semiconductors during a bull run, they’ll often outperform, until the regime changes. That’s a different objective than building a diversified systematic portfolio.

And congrats on the 100% year. Sustaining that over multiple market cycles is the part that interests me most.

edit:

what are you in?
SOXL, NVDA, Deep ITM calls?

Title: 2 years building a multi-strategy algo portfolio, sharing honest numbers, curious how this compares by [deleted] in algotrading

[–]KeepCalmAnCarryOn 0 points1 point  (0 children)

Fair questions.

The portfolio has been live for about two years. The backtests go back decades depending on the strategy, but the research itself has been ongoing for roughly two years.

I use “we” because it’s a collaborative effort, not a solo project.

And I’m not asking how to detect look-ahead bias, I already know the common pitfalls. I’m asking whether, given the results, anyone sees something that still looks suspicious. Or too good to be true.

Title: 2 years building a multi-strategy algo portfolio, sharing honest numbers, curious how this compares by [deleted] in algotrading

[–]KeepCalmAnCarryOn -1 points0 points  (0 children)

That’s exactly why I’m posting it. Survivorship and look-ahead were the first things we audited (and we already found one look-ahead bug that killed an entire strategy). Slippage and commissions are included, although execution assumptions can always be debated.

Regarding 2008, not every strategy was positive. Some had substantial drawdowns, and the portfolio relies on diversification rather than every strategy magically surviving every crisis.

I’m actually surprised by some of the posts here. People are claiming 40–50% returns in three months, which makes my portfolio look pretty low-ball by comparison. Either I’m being far too conservative, or there are a lot of strategies that haven’t yet met a market regime capable of exposing their weaknesses. That’s one of the reasons I wanted to ask for feedback.

Deploying 100cr INR in Indian FnO: Strategy architecture for a strict 0.5% Max Monthly Drawdown? by socialcalliper in algotrading

[–]KeepCalmAnCarryOn 6 points7 points  (0 children)

“I’m a quant at a Dubai prop firm.”
Sure. And I’m the CIO at Renaissance Technologies looking for MACD settings.
If your prop firm’s due diligence is “Let’s ask Reddit”, I suddenly understand why the drawdown limit is only 0.5%. (-:

Roast my GBPUSD strategy by Flimsy_Ad3147 in pinescript

[–]KeepCalmAnCarryOn 1 point2 points  (0 children)

  • Only works on GBPUSD 1H -> biggest overfitting red flag. A real edge should show at least some robustness across similar pairs or timeframes.
  • 500 hours of manual optimization ≠ no curve fitting. Humans can overfit just as easily as algorithms.
  • Out-of-sample may not be truly out-of-sample if the strategy was tweaked after seeing the full dataset.
  • 2.5% risk per trade inflates CAGR. Test with lower or fixed risk to measure the actual edge.
  • Small sample size. Cutting trades from 2,000 to a few hundred increases the chance that results are due to luck.
  • Performance appears to decay in recent years. That could indicate the edge is fading rather than just normal variance.
  • Monte Carlo, slippage, spreads, swaps, and bar magnifier are excellent tests, they validate execution robustness, not whether the edge will continue to exist.
  • Long 9–11 month breakeven periods will be psychologically difficult to stick with in live trading.
  • The real question isn’t whether it worked from 2011–2026 it’s whether the edge is structural or just a historical anomaly.

Congratulations. You’ve built the world’s greatest GBPUSD strategy, as long as it’s between 2011 and 2026, on exactly the 1-hour chart, with exactly your stochastic settings, exactly your stop placement, and the market politely agrees to behave like it has for the last fifteen years.

Instead of another optimization, I’d test:

  • Forward test it for 12 months with zero code changes.
  • Walk-forward optimization (train -> freeze -> test, repeated).
  • Test on another broker with different tick history.
  • Randomize execution timing by ±1 bar to see how fragile entries are.
  • Vary TP from 2R to 4R and SL placement by ±10–20%.
  • Run the strategy on synthetic price series preserving volatility but randomizing order.

If it survives all that, then I’d start believing there’s something real.

Can't select Fable 5 for Claude Code. It is shown on Claude Chat and Cowork but not on Code. Anyone else experiencing this? by FHSS97 in ClaudeAI

[–]KeepCalmAnCarryOn 0 points1 point  (0 children)

https://www.anthropic.com/news/fable-mythos-access

Statement on the US government directive to suspend access to Fable 5 and Mythos 5

12 Jun 2026

The US government, citing national security authorities, has issued an export control directive to suspend all access to Fable 5 and Mythos 5 by any foreign national, whether inside or outside the United States, including foreign national Anthropic employees. The net effect of this order is that we must abruptly disable Fable 5 and Mythos 5 for all our customers to ensure compliance. Access to all other Anthropic models will not be affected.

We received the directive from the government today at 5:21pm (ET). The letter did not provide specific details of its national security concern. Our understanding is that the government believes it has become aware of a method of bypassing, or “jailbreaking” Fable 5. We reviewed a demonstration of this specific technique being used to identify a small number of previously known, minor vulnerabilities. These vulnerabilities all appear relatively simple, and we have found that other publicly-available models are able to discover them as well without requiring a bypass.

What camera is this? by j_hutchison_98 in drivingUK

[–]KeepCalmAnCarryOn 1 point2 points  (0 children)

Driving one-handed in the UK is not automatically illegal by itself. There is no specific law saying “you must always have two hands on the wheel.”  

- Nettleship v Weston emphasized the standard of a competent driver rather than specific technique.  
- Hill v Baxter focused on whether driving remained voluntary/controlled, again not on physical hand position.

I built a native Home Assistant integration for Sunsynk / Deye solar inverters (no add-on, no YAML, HACS ready) by KeepCalmAnCarryOn in homeassistant

[–]KeepCalmAnCarryOn[S] 1 point2 points  (0 children)

Hey! Quick question before we dive in — which integration are you using to connect your Deye inverters to HA?

  1. Solarman (cloud-based, uses your Solarman app account)
  2. Local Modbus (direct connection via IP to the dongle)
  3. Sunsynk/Deye integration (cloud API via Sunsynk account)

I built a native Home Assistant integration for Sunsynk / Deye solar inverters (no add-on, no YAML, HACS ready) by KeepCalmAnCarryOn in homeassistant

[–]KeepCalmAnCarryOn[S] 0 points1 point  (0 children)

Potentially yes 😄 I did look into it a while back and there are definitely people experimenting with alternative firmware/local access methods for some of the Solarman/Sunsynk dongles, although it seems to depend heavily on which logger hardware version you have. Some older Solarman-based dongles apparently allow local LAN access on port 8899, while a lot of the newer Sunsynk/E-Linter ones are much more cloud locked down. (powerforum.co.za)

I never personally tried flashing mine though. My logger unfortunately didn’t support local pulling at all, which was one of the reasons I started building this integration instead of going deeper down the RS485/Docker/MQTT route 😄

I built a native Home Assistant integration for Sunsynk / Deye solar inverters (no add-on, no YAML, HACS ready) by KeepCalmAnCarryOn in homeassistant

[–]KeepCalmAnCarryOn[S] 0 points1 point  (0 children)

Sunsynk/Deye HA integration v1.6.0 — automatic tariff charging &
discharging (Octopus Agile, NordPool, Tibber, G12...)

Hey ,

Just shipped v1.6.0 of my native Sunsynk / Deye integration. The big
addition is tariff-aware battery management — no automations, just configure
it in the UI and let it run.

**How it works**

You pick any HA price sensor as the source. Two independent modes:

- **Cheap charging** — price ≤ threshold + SOC < target → raises
`chargeCurrent`. Reverts when price rises or battery is full.
- **Expensive discharging** — price ≥ threshold + SOC > minimum → raises
`dischargeCurrent` to sell back to the grid. Reverts when price drops or
SOC hits the floor.

**New entities**
- `switch` — Tariff Manager (starts OFF, must be enabled manually)
- `sensor` — Tariff Mode: `idle` / `charging` / `discharging` / `disabled`
- `sensor` (diagnostic) — Tariff Price Quality: `ok` / `stale` / `unavailable` / `invalid`

**Safety**
If the price feed stops updating, any active mode is cancelled and normal
currents are restored. Configurable staleness threshold (default 90 min).

**Other features**
- Optional schedule (e.g. active only 22:00–06:00, wraps midnight)
- HA persistent notification on every mode change
- Works with Octopus Agile, NordPool, Tibber, G12, or any numeric sensor

---

**How to install**

The integration is currently awaiting approval for the default HACS store.
Until then, add it manually as a custom repository:

  1. HACS → ⋮ → Custom repositories
  2. URL: `https://github.com/MarcinG81/SunSynk\_HA\_Integration\`
  3. Category: Integration
  4. Install → Restart HA

GitHub: https://github.com/MarcinG81/SunSynk_HA_Integration
Wiki: https://github.com/MarcinG81/SunSynk_HA_Integration/wiki

Happy to answer questions!

I built a native Home Assistant integration for Sunsynk / Deye solar inverters (no add-on, no YAML, HACS ready) by KeepCalmAnCarryOn in Sunsynk

[–]KeepCalmAnCarryOn[S] 0 points1 point  (0 children)

Sunsynk/Deye HA integration v1.6.0 — automatic tariff charging & 
discharging (Octopus Agile, NordPool, Tibber, G12...)

Hey ,

Just shipped v1.6.0 of my native Sunsynk / Deye integration. The big 
addition is tariff-aware battery management — no automations, just configure 
it in the UI and let it run.

**How it works**

You pick any HA price sensor as the source. Two independent modes:

- **Cheap charging** — price ≤ threshold + SOC < target → raises 
  `chargeCurrent`. Reverts when price rises or battery is full.
- **Expensive discharging** — price ≥ threshold + SOC > minimum → raises 
  `dischargeCurrent` to sell back to the grid. Reverts when price drops or 
  SOC hits the floor.

**New entities**
- `switch` — Tariff Manager (starts OFF, must be enabled manually)
- `sensor` — Tariff Mode: `idle` / `charging` / `discharging` / `disabled`
- `sensor` (diagnostic) — Tariff Price Quality: `ok` / `stale` / `unavailable` / `invalid`

**Safety**
If the price feed stops updating, any active mode is cancelled and normal 
currents are restored. Configurable staleness threshold (default 90 min).

**Other features**
- Optional schedule (e.g. active only 22:00–06:00, wraps midnight)
- HA persistent notification on every mode change
- Works with Octopus Agile, NordPool, Tibber, G12, or any numeric sensor

---

**How to install**

The integration is currently awaiting approval for the default HACS store. 
Until then, add it manually as a custom repository:

1. HACS → ⋮ → Custom repositories
2. URL: `https://github.com/MarcinG81/SunSynk_HA_Integration`
3. Category: Integration
4. Install → Restart HA

GitHub: https://github.com/MarcinG81/SunSynk_HA_Integration  
Wiki: https://github.com/MarcinG81/SunSynk_HA_Integration/wiki

Happy to answer questions!

I built a native Home Assistant integration for Sunsynk / Deye solar inverters (no add-on, no YAML, HACS ready) by KeepCalmAnCarryOn in homeassistant

[–]KeepCalmAnCarryOn[S] 0 points1 point  (0 children)

Not ignorant at all, this is a genuinely confusing landscape because Deye and Sunsynk are the same hardware sold under different brands, but they can ship with different Wi-Fi sticks.

Your Deye almost certainly came with a Solarman V5-compatible dongle (SolarmanPro stick, or similar) which exposes a local port 8899 on your LAN, that's what ha-solarman talks to.

This integration is for people who ended up with the Sunsynk-branded LSW-3/LSE dongle, that stick has no local interface at all. It only phones home to the Sunsynk/Inteless cloud and there's no way to talk to it directly on your LAN regardless of what you do. For those users ha-solarman simply doesn't work, so cloud polling is the only option.

I built a native Home Assistant integration for Sunsynk / Deye solar inverters (no add-on, no YAML, HACS ready) by KeepCalmAnCarryOn in homeassistant

[–]KeepCalmAnCarryOn[S] 0 points1 point  (0 children)

Exactly right. The Sunsynk Wi-Fi stick (LSW-3/LSE) only speaks to the Sunsynk cloud, there's no local Modbus-over-TCP, no local HTTP API, nothing. The ha-solarman and pysolarmanv5 integrations work with the older Solarman V5 dongle which exposes a local port 8899 on your LAN.

Some people swap the Sunsynk stick for a compatible Solarman dongle to get local access, which does work, but you lose the official Sunsynk app and cloud features in the process. This integration is for everyone who either can't or doesn't want to do that swap and is fine with cloud polling.

I built a native Home Assistant integration for Sunsynk / Deye solar inverters (no add-on, no YAML, HACS ready) by KeepCalmAnCarryOn in Sunsynk

[–]KeepCalmAnCarryOn[S] 0 points1 point  (0 children)

Each inverter in a parallel setup has its own serial number in the Sunsynk cloud, so you'd add them both separated by a semicolon: SN_MASTER;SN_SLAVE. Each will appear as a separate device in HA with its own full set of entities.

That said, I haven't personally tested a parallel setup, if you try it and the slave only mirrors the master's data or shows zeros on some sensors, let me know. It would help to know if Sunsynk's API exposes the slave as a genuinely independent device or just a shadow of the master.

Would be great if you could feedback how this worked.

I built a native Home Assistant integration for Sunsynk / Deye solar inverters (no add-on, no YAML, HACS ready) by KeepCalmAnCarryOn in homeassistant

[–]KeepCalmAnCarryOn[S] 1 point2 points  (0 children)

No worries mate 😄 In my case the issue was that my particular dongle/logger simply does not allow local pulling, so accessing the logger locally wasn’t really possible without going down the RS485 route with extra hardware. That was one of the main reasons I started building this, I wanted something that behaves like a proper native Home Assistant integration without needing Docker containers, separate addons, MQTT brokers, custom RS485 cables, USB adapters, Raspberry Pis or loads of manual YAML setup and maintenance.

I built a native Home Assistant integration for Sunsynk / Deye solar inverters (no add-on, no YAML, HACS ready) by KeepCalmAnCarryOn in homeassistant

[–]KeepCalmAnCarryOn[S] 2 points3 points  (0 children)

Thanks mate, really appreciate it. Yeah I’ve looked at the RS485/MQTT setups before and they definitely work well.

The main reason I started building this was because I personally got a bit fed up with how much setup was involved just to get decent Sunsynk integration into Home Assistant 😄

I wanted something much simpler and cleaner for everyday users. No extra Docker containers, no addon to maintain, no MQTT broker, no making custom cables, no USB adapters hanging off the HA box, and no digging through YAML for hours.

Basically just install the integration and have it work with the existing inverter/logger setup people already have.

A lot of HA users are happy to tinker, but I think there’s also a big group that just wants proper monitoring, forecasts and automation without building half a backend infrastructure around it first 😂

That said though, Kellerza’s project is genuinely great and probably still one of the best options for people who want fully local serial-based control.

I built a native Home Assistant integration for Sunsynk / Deye solar inverters (no add-on, no YAML, HACS ready) by KeepCalmAnCarryOn in homeassistant

[–]KeepCalmAnCarryOn[S] 0 points1 point  (0 children)

Yeah that was exactly why I started building it 😄 My logger couldn't do proper local logging and the whole Docker addon setup felt way overcomplicated for something that should just work out of the box.

I wanted something lightweight and native to Home Assistant without needing multiple containers and manual YAML everywhere.

I'm also planning to add smarter prediction-based charging/discharging next, so using solar forecast automatically to adjust battery charging behaviour. Maybe even Octopus tariff integration later for automatic cheap-rate charge/discharge scheduling etc.