Studer ComBus teardown

[Jusufs]

XTH mam v mode control teda ako slave a BMS US3000 je master. Takze je mozne, ze navrat tych parametrov na flash hodnoru sposobuje algoritmus regulacie XTHcka.

Moze mi niekto vysvetlit vyznam hodnot na RCC pre Xcom CAN BMS advanced parametre prosim ?
- P6070 - SOC level under which battery discharge is stopped *0/15*100*EX
- P6062 - SOC level for backup *0/100*100*EX
- P6063 - SOC level for grid feeding *0/100*100*EX
- P6075 - SOC level for end of charge *80*100*100*EX
- P6078 - Charge current limit ratio *80*80*95*EX
- P6066 - Manufacturer SOC for 0% displayed *0*0*60*EX
- P6067 - Manufacturer SOC for 100% displayed *80*100*100*EX

Mylsim vyznam tych bold terazcov. Je to niekde popisane ?

[DanoP]

minimum/maximum/default/opravnenie -len v tvojom pripade neviem v akom poradi, resp. ktore je default

[Milhaus]

minimum/maximum/default/opravnenie -len v tvojom pripade neviem v akom poradi, resp. ktore je default

minimální nastavitelná hodnota / nastavená hodnota / maximální možná hodnota / úroveň která může měnit hodnoty

pozor pokud je 1550 nastaven na OFF - prostřední hodnota neukáže změněnou hodnotu ale původní před vypnutím 1550

a hvězdička u čísla značí tovární hodnotu.

[Jusufs]

Vdaka.

[Jusufs]

No ved tak som to myslel, ze sa vracaju do flash stavu. Ine si v RAM uchovaju hodnotu unsaved az do dalsieho vyp/zap xtendra.

[Jusufs]

Chcel by som sa spytat YOLA80 na moznost sucasnej komunikacie cez Xcom CAN adapter.

Prve rozhranie mam prepojene s US3000 mastrom.
Na druhe by som pripojil Rpi4 s CAN HATom.

Budem moct nastavit DIP Xcom CAN adaptera na master alebo inspect pre Pylontech US typ a sucasne komunikovat cez CAN HAT na RPi v Tor\lerantnom protocol mode ?

[Jusufs]

Takze bordel s 1550 sposobuje Xcom CAN adapter. Pokial ho nemate v retazci Studer zariadeni, hodnota 1550 No sa skutocne odpamata.
Pokial v retazci je tento modul, pravdepodobne pri restarte nahadzuje 1550ku na Yes. Potvrdil mi to aj pracovnik supportu Studer. Ide za vyvojarmi.

[vladimir.dvorak]

Zdravím,

Podařilo se mi "zprovoznit" komunikaci s se systémem xts1400-48, VT-65, rcc02 a Xcom CAN pomoci RPi 3B a CAN hatu od waweshare (jednokamalovy s CAN a RS485). Baterie je pylontech us5000. Polling asi 12 parametrů je po cca 1 minute. Bohužel se mi stává, že náhodně přicházím o Xcom CAN (hláška communication with lithium battery lost), který vyhlasi chybu a tím celá FVE jde do failu. Xcom CAN je pak nutné odpojí a znovu připojit.

Nejdříve jsem mel RPi povedené přímo na Xcom CAN ze strany Studer sběrnice. Pak jsem jej umístil na rcc02. K padum dozachi stále. Někdy co 3 hodiny. Jindy je několik dní klid. Terminátory jsou nastavené správně.

Při posledním výpadku jsem si uvědomil, že k výpadkům dochází pouze za provozu z baterie a zda se jen tehdy, když startuje lednice.

Můžu jen odhadovat, jestli to nemá náhodou na svědomí neizolovany CAN hat od waweshare skrze nějaký napětovy raz od startu lednice.

Nemáte to někdo podobně?

Pokud by měl někdo nějaký nápad, budu určitě rád.

Díky

V

[yolo80]

Můžu jen odhadovat, jestli to nemá náhodou na svědomí neizolovany CAN hat od waweshare skrze nějaký napětovy raz od startu lednice.

CAN hat aj Rpi mas napajany z impulzneho zdroja 230V/5V a ten zabezpecuje izolaciu (predpokladam ze to tak napajas). Typujem to na kolisanie napajania 5V pri zopnuti chladnicky. Riesenie je dat nejaky vacsi kondenzator na napajanie Rpi.

[vladimir.dvorak]

Zdravím Yolo80.

Díky za příspěvek. RPi napájím PoE že switche QNAP (kabel cca 20m). Switch jede na samostatne UPS, která je napájena výstupem invertoru. Možná bych mohl zkusit RPi napájet samostatným zdrojem ze zásuvky na jiné fázi než je invertor.

Zkusím a dám vědět.

V

[mgx]

napajam POE/POE switch priamo z DC baterie48V

[josse]

napajam POE/POE switch priamo z DC baterie48V

POE switch je velice elegantní...
Pozor na ty moduly do RPi nebo i s USB-C/mikro... U všech existuje galvanicky oddělená I neoddělená varianta... Pozor na propojení zemí po těchto napáječích přes UTP. Ten switch je totiž galvanicky spojený s Aku na 48V. Dokonce pro někoho kdo má bočník v - je to ještě horší situace ... Kovový switch POE má na kostře minus...

[brumlaj]

Jak kdyby neexistovalo TELCO standard - uzemněný plus. Ale co je odbyté to je levné. A co je levné, to se dobře prodává.

[kolin]

Ahoj,
yolo80 díky za zveřejnění informací. Už také odposlouchávám sběrnici. Muselo to zabrat hodně přemýšlení. Už jsem hackoval CAN komunikaci, ale ta byla trivialní proti téhle.

Studer mam zatím zapojedný jeden na baterii a hraju si s tím (časem bude 3f s AC coupling). Trochu mě rozčiluje, že pro komunikaci se Studer Portalem potřebuju XCOM-232 + převodník na ethernet, pak mi ale nechodí scom.exe, protože to mluví jiným protokolem (asi, úplně podbrobně jsem to nestudoval)

Pro komunikaci s baterkou mam XCOM-CAN, ale ten je zase obsazený tou baterií. Takže jejich OpenStuder CAN protokol si použít nemůžu.

Buď bych potřeboval další XCOM-232 nebo XCOM-CAN na svoje komunikace do HomeAssistantu. To je za prvé drahé a za druhé ani nevím, jestli tam být můžou.

Takže asi nejsnažší možnost bude opravdu krást data přímo z jejich "Proprietary Studer Bus".

Zatím jsem si ručně poslal packet a dostal odpověď:

Kód: Vybrat vše

cansend can0 152110E2#00890088

Kód: Vybrat vše

can0  TX - -  152110E2   [4]  00 89 00 88
can0  RX - -  1520E016   [8]  00 89 00 00 00 88 01 0F

kde 01 0F odpovídá 271W kter0 v tu dobu Studer produkoval.

Asi by nebylo úplně složité sestavit .yaml do esphome, kde by vysílal requesty na sběrnici a odchytával a parsoval odpovědi:
https://esphome.io/components/canbus.html?highlight=can#


Chtěl jsem poprosit, jestli by jsi byl ochoten nasdílet nějaké kousky tvých python skriptů. A případně napsat nějaký update.
Díky