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

[Arambajk]

Ahoj, zapojil jsem na CAN sběrnici jednoduchý indikátor zatížení s MAX3051 a STM32F103. Aby reagoval rychle, každou vteřinu do sběrnice odesílám dotaz na výkon,

Kód: Vybrat vše

152110E3 [2] 00 88

Odpovědi z 2 XTM zobrazím na led bargrafu. Měsíc to fungovalo bezproblému až jeden večer mi na VS70 bliká error 6 - nekompatibilní SW. Pomohl až restart baterek.

Není lepší posílat zprávu s ID RCC03, které na sběrnici už je místo ID zařízení, které tam vůbec není? Ještě jsem zkusil místo 2 bajtů posílat 4, tak jak to dělá RCC a uvidím, jestli to bude spolehlivější. Možná indikátor předělám na komunikaci s Xcom-232, ale tomu jsem se původně chtěl vyhnout, protože mi přijde, že ten Xcom zbytečně docela topí a na logování už tam mám RCC03.

Jinak, zajímavé je, že v manuálu je u všech hodnot formát float a skutečně napětí baterky a panelů posílají jako 16bit float, výkon z XTM je ale integer.
Dále, CAN sběrnice je sice robustní, ale když omylem odešlete zprávu s ID 0, tak je to okamžité cvak a tma a hláška "bylo připojeno zařízení s nekompatibilním SW." Zprávy s nízkým ID a tedy vysokou prioritou jsou možná vyhrazeny pro poruchy.

schema.png (40.64 KiB) Zobrazeno 986 x

IMG_0626_25.JPG (409.32 KiB) Zobrazeno 986 x

[yolo80]

Odpovědi z 2 XTM zobrazím na led bargrafu. Měsíc to fungovalo bezproblému až jeden večer mi na VS70 bliká error 6 - nekompatibilní SW. Pomohl až restart baterek.

Zaujimave ze zhavarovala VS70 a dotaz si posielal na vykon XTM

Není lepší posílat zprávu s ID RCC03, které na sběrnici už je místo ID zařízení, které tam vůbec není?

Ja to takto pouzivam a adresa z ktorej posielam dotaz je adresa RCC ktore je na zbernici

Dále, CAN sběrnice je sice robustní, ale když omylem odešlete zprávu s ID 0, tak je to okamžité cvak a tma a hláška "bylo připojeno zařízení s nekompatibilním SW."

cvak a tma sa uz podarila aj mne, ale dotaz "bylo připojeno zařízení s nekompatibilním SW" som zatial este nevidel.