Dokumentation

Användardefinierade räknare

Obs: cFos Charging Manager kan läsa av de flesta solvärmare som använder SunSpec (enhetstyp "SunSpec Solar Inverter / Meter"). I detta fall behöver du inte skapa en egen mätardefinition.

Med cFos Charging Manager kan du skapa egna mätardefinitioner för att stödja mätare som inte finns i standardrepertoaren. Det finns för närvarande tre typer: Modbus-räknare, HTTP/JSON-räknare och MQTT/JSON-räknare. Definitionsfilerna för dessa räknare är mycket lika varandra. Modbus-räknare läser sina data via Modbus från specifika register, medan HTTP/JSON-räknare hämtar sina data via en HTTP-förfrågan och analyserar JSON som svar. För MQTT/JSON-räknare prenumererar cFos Charging Manager på MQTT-ämnen och analyserar meddelanden som publiceras under ämnet som JSON. För att analysera använder cFos Charging Manager ett litet "frågespråk". Här finns dokumentation om MQTT-funktionerna i cFos Charging Manager.

Förutom ett antal fördefinierade variabler, t.ex. ström och spänning, kan användardefinierade räknare också läsa in okända användardefinierade variabler, fråga efter ingångar och ställa in utgångar. Genom att läsa in variabler och ställa in utgångar kan formler utvärderas. I kombination med Charging Manager-variablerna och de globala Charging Manager-utgångarna som beskrivs nedan är detta en kraftfull funktion som till och med gör det möjligt att utföra vissa hemautomatiseringsuppgifter och styra externa enheter, t.ex. batterilager. Om du har kontrolluppgifter med detta, vänligen ge oss feedback. Vi är mycket intresserade av vad folk kontrollerar med cFos Charging Manager och det hjälper oss att vidareutveckla Charging Manager enligt kundernas behov.

Här är en enkel exempeldefinition för Modbus som läser ett enda register för aktiv effekt. Du kan enkelt ändra registernumret för din specifika tillämpning:
Exempel på en definition för ett enda register.

Här finns en exempeldefinition för Modbus och en för HTTP/JSON:
Ladda ner exempeldefinitionen för Modbus-mätare
Ladda ner exempeldefinitionen för HTTP/JSON-mätare

Charging Manager har redan några sådana filer, men du kan ladda upp dina egna filer under "Systemkonfiguration" och även radera dem igen.
Här hittar du de flesta av de definitioner av mätare som vi tillhandahåller:
Ladda ner medföljande definitioner av räknare

Om du har skapat en egen räknesystemfil och den kan vara relevant för andra användare, skulle vi vara mycket tacksamma om du kunde göra den tillgänglig för oss. Då kommer vi att leverera den med framtida versioner av Charging Manager.

Ladda ner mätardefinitioner för ytterligare mätare

Strukturen för en definitionsfil:

Räknardefinitioner är JSON-filer med ett globalt JSON-objekt som har egenskaper och underobjekt. "rtype" bestämmer typen av läsoperation: 0 = Modbus, 1 = HTTP/JSON, 2 = MQTT/JSON. "mtype" bestämmer enhetstypen: 0 = annan enhet, 1 = mätare, 2 = växelriktare, 4 = batterilagring.

Du kan ange siffror antingen i decimal eller hex med prefixet 0x. Kommentarer på en rad med // är också tillåtna.

Vi rekommenderar att du kör dina definitionsfiler genom en JSON5-validator, t.ex. denna JSON5-validator Du bör definitivt ha läst kapitlet Formler för att förstå vilka värden som kan användas i formler i följande referens.

Modbusdefinitioner har ett objekt "rtu" med följande egenskaper:

silence_period, i msek. bestäms, pauslängden före en Modbus RTU-åtkomst, så att enheten känner igen början av ett meddelande.
silence_same_slave, true: Pausen observeras också vid flera åtkomster till samma enhet.
retries: Antalet försök om enheten inte svarar.
rcv_timeout: i msek. den maximala väntetiden per åtkomst tills enheten svarar.

Dessa globala egenskaper gäller för Modbus TCP och RTU:

modbus_read: Funktionsnumret för Modbus-läsningskommandot, vanligtvis 3 eller 4.
modbus_read_max_registers: Det maximala antalet register som kan läsas samtidigt.
modbus_allow_gaps: true = Oanvända registerområden kan läsas i en läshändelse.

För Modbus TCP och HTTP/JSON finns det ett objekt "tcp" med följande egenskaper:

connect_timeout: är msek. den maximala väntetiden för en TCP-anslutning.
delay_after_connect: i msek. Gör en paus efter att anslutningen har upprättats innan du skickar det första kommandot.

Båda definitionstyperna (Modbus och HTTP/JSON) har följande ytterligare egenskaper:

upd_delay: i msek. bestämmer det intervall inom vilket en enhet kan läsas. Vissa enheter överbelastas om de tillfrågas för ofta.
manufacturer: String, namn på tillverkaren. Detta visas i brickans utökade information.
delay_accumulated: true = Ackumulerade värden (kWh) efterfrågas endast var 3:e sekund eller om det finns tillräckligt med ström. false = Dessa värden efterfrågas alltid.
ui_addr: URL, om den skiljer sig från enhetens adress för anrop av webbgränssnittet.
reserved: Array med värden som tolkas som 0 (användbart om enheten stöder vissa värden beroende på modell).

Om du utelämnar de egenskaper som anges ovan tar cFos Charging Manager standardvärden som fungerar bra i de flesta fall.

I JSON-definitionen är nästa steg att definiera variabler som mätaren använder för att läsa av eller beräkna värden för ström, spänning etc. Följande variabler används av laddningshanteraren. Laddningshanteraren känner till följande variabler:
type_designation, version, firmware_version, serial: Dessa bildar modellnamnet som visas i den utökade informationen för brickan. Dessa efterfrågas en gång när mätaren konfigureras eller återställs.
voltage_l1..voltage_l3, current_l1..current_l3, power_w, power_var, power_va, power_w_l1..power_w_l3: CFos Charging Manager försöker beräkna värden för voltage_l1..l3, signed current_l1..l3, power_w och power_va från dessa. Du behöver inte ange alla variabler. CFos Charging Manager försöker beräkna värdena från de befintliga variablerna.
import_wh, export_wh: Charging Manager använder dessa variabler för att visa import_wh och export_wh. För enkelriktade mätare (t.ex. växelriktare) ska du alltid endast definiera import_wh. Export_wh ska endast definieras för dubbelriktade mätare (t.ex. ackumulatortankar eller referensmätare för nätet).

soc: Om tillgängligt visas laddningsstatus för en ackumulatortank i % i brickan.
Dessutom kan du definiera andra variabler med olika namn som läses upp vid varje uppdatering eller beräknas med hjälp av formler. Om du definierar variabler som börjar med CM., t.ex. CM._set_price, lagras de tilldelade värdena i de globala Charging Manager-variablerna (se nedan) och kan efterfrågas på motsvarande sätt.
Variabler med *: Om du definierar variabler som börjar med * visas de i användargränssnittet i mätarens ruta under utökad information, t.ex. temperaturen i ett batterilager.

Definition av en variabel:


Objektet är döpt efter namnet på variabeln som anges ovan och har följande egenskaper: fixed: Sträng med ett fast värde.

Användbart om t.ex. inget värde kan bestämmas, t.ex. för typbeteckning eller spänning. expr: Sträng, variabeln läses inte ut utan utvärderas som en formel. type: Om inte fixed eller expr, variabelns typ: int16, uint16, int32, uint32, float, int64, string. Detta är viktigt för Modbus för att kunna läsa registren i rätt format. uint16 och uint32 är typer som bara kan acceptera positiva tal.
Med JSON/HTTP kan du vanligtvis använda float. resolution: float, det lästa värdet multipliceras med "resolution". Värden för spänning måste vara i volt, ström i milliampere, effekt i watt, energi i watt-timmar (Wh).


Med negativ "upplösning" kan du invertera ett värde om det har motsatt tecken. once: bool (true eller false), om true läses värdet endast en gång när enheten initieras, annars periodiskt. address: nummer (Modbus) eller sträng (HTTP/JSON), Modbus-registernumret eller HTTP-URL:en för det värde som ska läsas. query:
Sträng, för HTTP JSON specifikationen i frågespråket för Charging Manager med vilken den hittar det värde som ska läsas i JSON-svaret. order: Sträng, för Modbus byteordningen, antingen "hl" eller "lh", i vilken värdet finns. length: number, för Modbus längden på en sträng i register. För variablerna "version" och "firmware_version" används "length" för att omvandla numeriska versioner till strängar med punkter. Värdena 2 eller 4 är tillåtna för 'length', vilket resulterar i versionsformaten a.b och a.b.c.d. Med 'length' 2 och typ 'int16' eller 'uint16' separerar Charging Manager låg- och högbyte med en punkt, med 'int32' eller 'uint32' låg- och högord, med 'int64' låg- och högord. För 'lenth' 4 och 'int32' eller 'uint32' delar avgiftsadministratören upp värdet i 4 byte åtskilda av en punkt.
För 'int64' är de 4 orden i enlighet med detta. regex: Sträng. Om ett reguljärt uttryck anges behöver räknesvaret inte vara i JSON. Antingen utvärderas hela matchningen av det reguljära uttrycket eller den första gruppen som resultat. Använd endast detta om enheten inte returnerar JSON.

Här är en lista över funktioner i våra reguljära uttryck: alla tecken: . namngivna klasser:



\d \s \w \D \S \W anonyma klasser: [a-z0-9_], [^0-9], [^\d] grupper med alternativ: (ab|cd|ef) icke-fångade grupper: (?:ab|cd) (greedy) en gång eller ingen: a??, a???
(girig) många eller inga: a*, a*?


(greedy) en eller flera gånger: a+, a+? början av strängen: ^ slutet av strängen: $

Definition av insatsvaror:

Charging Manager kan fråga upp till 32 ingångsvärden från olika register eller JSON-element per enhet. Egenskapen "Inputs" är en JSON-array. Du måste definiera följande egenskaper för varje ingång:
adress: Adress (Modbus-register eller URL).
räkna: Antal inmatningsbitar som kommer att läsas med denna begäran.
query: För HTTP/JSON, frågespråk för att hitta värdet i svaret.

CFos Charging Manager läser alla ingångar som definierats på detta sätt vid varje uppdatering och placerar bitarna internt i en matris, som sedan kan frågas ut i formlerna Input1..InputN...

Definition av utfall:

Laddningshanteraren kan växla upp till 32 utgångar per enhet. Utgångar definieras i "utgångar" som en JSON-array av utgångsobjekt. Alla utgångar kopplas i slutet av varje uppdateringscykel om statusen för respektive utgång har ändrats.
För varje utgång måste du definiera följande egenskaper i utgångsobjektet:
adress: HTTP URL med valfri HTTP-metod, t.ex. GET http://www.example.com?output1=${var1}. För att ställa in Modbus-register kan du använda HTTP API för cFos Charging Manager. Laddningshanteraren upptäcker matchande åtkomster på localhost och omdirigerar begäran till den interna hanteraren, så du behöver inte auktorisering som med externa HTTP API-åtkomster. Om URL:en är tom efter alla utbyten anges ingen utmatning. Du kan till exempel bara växla utdata om vissa variabler finns (se formler: funktionen exists()). I adressen kan du dessutom ange ${address} och ${id}. Detta är den aktuella enhetsadressen och Modbus ID som definierats i inställningarna. Adress och id används huvudsakligen för att använda Modbus API (se nedan).
body: Valfri HTTP body för POST eller PUT.
I URL och body kan du använda ${expr}-formler som refererar till globala Charging Manager-variabler eller från respektive räknare. Formeln 'expr' utvärderas när utdata ställs in och ersätts i texten i URL:en eller brödtexten. Om, i exemplet ovan, http://www.example.com?output1=1 ställer in utmatningen och http://www.example.com?output1=0 tar bort den, kan du definiera en variabel 'var1' och ställa in den på 1 eller 0 efter önskemål. På detta sätt kan du också skriva numeriska värden för att styra minnesprestanda i Modbus-register som du tidigare har lagrat i en variabel med hjälp av en formel.
Om du istället för att skicka ett numeriskt värde i URL:en behöver ersätta en text med en annan beroende på formeln, t.ex. med Shelly WLAN-uttag, kan du skriva det så här: ${if expr`text1`text2}. 'Apostrofen' är ett backtick (ASCII-kod 96). Om 'expr' != 0 infogas text1, annars text2. För Shelly WLAN-uttaget ser URL:en ut så här: http://<ip-addr>/relay/0?turn=${if expr`on`off}, dvs. om expr != 0 anropar laddningshanteraren http://<ip-addr>/relay/0?turn=on, annars http://<ip-addr>/relay/0?turn=off.

Om du anger en relativ sökväg som URL tar laddningshanteraren den adress som konfigurerats för respektive enhet. Om du anger "localhost" som domän tar Laddningshanteraren adressen till den enhet som den körs på. Om den upptäcker en åtkomst till sitt eget API använder den den interna hanteraren istället för att utföra en fullständig HTTP-åtkomst, så att du inte behöver lagra ett användarnamn och lösenord i räknardefinitionen. En URL som börjar med en * kommer att leda till att laddningshanteraren alltid utför en fullständig HTTP-åtkomst.

Återställ utgångar: Förutom en "outputs"-array kan du även definiera en array med namnet "resets" som är strukturerad på samma sätt som "outputs"-arrayen. Detta kan användas för att återställa utgångar till sina ursprungliga värden när enheten avaktiveras. Med detta, i kombination med användardefinierade variabler och "once": true, kan du återställa enheten till dess ursprungliga tillstånd.
Skriv utgångar periodiskt: För vissa enheter måste utgångarna skrivas med jämna mellanrum, annars återställer enheten värdena till "standard". Kostal-minnet använder t.ex. sina standardregler igen om minneskontrollen inte har skrivits aktivt på ett tag. För att ställa in utgångar periodiskt kan du prefixa adressen med #xxx#, där xxx anger hur många sekunder som utgången skrivs om, även om värdet som skall skrivas är detsamma. Om adressen t.ex. är /cnf?cmd=set_cm_vars&name=test&val=42, kan du använda #30#/cnf?cmd=set_cm_vars&name=test&val=42 för att se till att detta värde skrivs var 30:e sekund.

Definition av språk för förfrågningar:

För närvarande kan medlemsnamn och operatörerna "." och "[]" användas i sökuttrycken "query", till exempel:

testElement med namnet "test"
name1.name2Elementet "name2" i underobjektet "name1"
namn[idx]Elementet "idx" i objektelementet "name". "idx" kan vara ett nummer, t.ex. för matriser, eller en sträng
name["u2"]Elementet "u2" i objektelementet "name", motsvarar "name.u2"
name[{"el1": "v1", "el2": 3}].valueVälj det element i matrisen som uppfyller villkoren i objektsnotationen och utvärdera elementet som heter "value". Här väljs till exempel i matrisen "name" det element som har som objektelement "el1" med värdet "v1" och "el2" med värdet 3, och sedan returneras värdet av elementet "value" från detta objekt.

Variabler för Global Charging Manager:

Du kan skapa variabler i konfigurationen för Charging Manager. Du kan använda ett fast värde eller en formel som värde. I slutet av varje uppdateringscykel räknar Charging Manager om värdet på dessa variabler om det behövs. Du kan sedan använda dem i (vissa) parametrar för Charging Manager, Charging Rules eller för att styra utgångar. Du kan också skriva Ex.member eller Mx.member som variabler. Här är Exoch Mxenhetens ID för en vägglåda eller mätare som har ställts in i Charging Manager. member är en "användardefinierad" variabel som lagras i motsvarande enhet. Vissa av variablerna kan ha en speciell betydelse: För KEBA är "out1" en kopplingsutgång, för ABB B23-mätare är "out1" och "out2" kopplingsutgångar (för modeller som stöder detta). En 1 kopplar om utgången, en 0 stänger av den igen.

Om du har apparater som måste slås på under vissa förhållanden men som sedan körs ett tag (t.ex. tvättmaskin, diskmaskin) kan du också definiera variabeln som en "trigger". Då är variabelns formel det villkor under vilket variabeln sätts till 1. Efter en inställbar tid sätts den sedan till 0 igen. Ett "retriggervillkor" gör att tiden fram till avstängning (dvs. variabeln sätts till 0) kan förlängas om och om igen så länge villkoret är uppfyllt.

För teständamål kan du visa Charging Manager och mätarvariabler, t.ex. de aktuella Awattar-priserna:


                        Skärmbildsvisning av räknevariabler

Global Charging Manager Utgångar:

I konfigurationen av Charging Manager kan du konfigurera globala utgångar enligt beskrivningen ovan i räknardefinitionen under "Outputs". Dessa sätts i slutet av varje uppdateringscykel om deras status har ändrats. Om du vill styra växlingsutgångar i användardefinierade enheter rekommenderas ovanstående konvention (se Variabler för laddningshanteraren): Du ställer in variabler med namnen "out1", "out2" osv. i den användardefinierade räknaren och ställer in utgångar i den användardefinierade räknaren som växlar utgången beroende på värdet på dessa variabler.

Globalt Modbus API för Charging Manager:

Modbus API i Charging Manager används för att styra Modbus-enheter som har en Modbus RTU- eller TCP-adress (tillgänglig från Charging Manager). För Modbus RTU anger du COMx,bd,8,p,s som adress, där x är COM-portnumret, bd är byggnadsfrekvensen, p är pariteten ("N", "E" eller "O") och s är antalet stoppbitar (1 eller 2), enligt konfigurationen av de enskilda enheterna. För Modbus TCP är adressaten IP-adressen för enheten i Charging Managers nätverk inklusive portnumret.
URL:en (för HTTP GET) för Modbus API är:
/cnf?cmd=modbus_get eller /cnf?cmd=modbus_set
cFos Charging Manager stöder följande ytterligare frågeparametrar:
addr: Modbus RTU- eller TCP-enhetsadressen som nämns ovan.
func: Modbus-funktionsnummer, t.ex. för läsning 3 eller 4, för skrivning 6 eller 16.
id: Modbus-enhetens enhets-ID.
reg: Modbus-registernummer. Värdet kan anges i decimaltal eller hexadikalt (med prefixet 0x).
val: nummer, värde som ska skrivas in i registret. Utelämna vid läsning.
typ: "w" 16bit (standard), d = 32bit, f = float, q = 64bit, s = sträng.
cnt: Tal, strängens maximala längd i register, utelämna för andra typer eller sätts till 1.
order: Sträng, byteordningen, antingen "hl" eller "lh".

Observera: Om din "counter" i första hand har kontrolluppgifter kan du kryssa för alternativet "Dölj enhet" i inställningarna för den här plattan så att enheten inte visas på startsidan.

Observera: Vissa mätare som avläses via HTTP kräver ett användarnamn/lösenord som behörighet. Du kan ange detta i adressen för HTTP-åtkomst, t.ex. med http://username:password@192.168.2.111. Om ditt användarnamn eller lösenord innehåller ett "@" måste du ersätta det med "%40".