Live MQTT Control

Deze handleiding helpt u MQTT te configureren op uw SmartgridOne Controller om batterij- en zonnepaneelinstallaties op afstand te bedienen en te monitoren.

Eerste configuratie (startpunt voor nieuwe gebruikers)

Ik heb een SmartgridOne Controller die ik wil instellen voor MQTT Remote Control.

Zorg ervoor dat uw netwerk en apparaten gereed zijn door de MQTT SetupScheduler-interval

Vraag de vereiste Eniris MQTT-gebruikersnaam en het wachtwoord aan via deEniris-webshop voordat u met de configuratie begint. Supporttickets en SmartgridX/Insights zijn geen provisioningkanalen voor nieuwe MQTT-inloggegevens.

1. Het MQTT-externe signaal toevoegen

2. Het MQTT-signaal voor bediening op afstand inschakelen

De time-out van het fallbackmechanisme vertelt de SmartgridOne Controller hoe lang deze op nieuwe opdrachten moet wachten. Wanneer de SmartgridOne Controller geen opdrachten meer ontvangt, neemt deze na deze time-out automatisch de standaardstrategie over.

Selecteer vervolgens alle apparaten die u in MQTT Remote Control wilt opnemen.

3. Het signaal voor bediening op afstand is toegevoegd

De interface voor MQTT Remote Control is nu geactiveerd op de SmartgridOne Controller.

We zijn nu klaar om met een eenvoudig voorbeeld enkele basisopdrachten te verzenden. De kolom Status geeft aan of er een opdracht actief is.

Python-demonstratiescript

Een goed begin is om uw nieuw geconfigureerde integratie met een eenvoudig voorbeeld te testen.

Deze testcode verzendt continu de volgende opdrachten:

• Batterij: opladen met 5 kW
• Zon: vermogen instellen op 0 kW

De SmartgridOne Controller reageert continu met een 'feedback'-bericht met de waargenomen waarden voor net- en assetvermogen. Deze functie is ook in dit voorbeeld opgenomen.

Download het onderstaande bestand in uw favoriete Python-IDE. Vul uw serienummer en de MQTT-inloggegevens in die u via de Eniris-webshop, en voer vervolgens het script uit:

Als het bovenstaande succesvol is, kunt u doorgaan met het verzenden van andere typen opdrachten. Alle opdrachten worden beschreven in onze documentatie voor MQTT Remote Control.

MQTT-documentatie voor het verzenden van opdrachten

In dit gedeelte worden de MQTT-berichtenindeling en payloadvereisten beschreven voor het op afstand beheren van vermogensbeleid op apparaten binnen het netwerk van de SmartgridOne Controller's netwerk.

MQTT Topic

Het MQTT-topic voor het verzenden van opdrachten heeft de volgende structuur:

standard1/rp_one_s/remoteControlMetrics/'controller SN'

Waarbij 'controller SN' moet worden vervangen door het werkelijke serienummer van de SmartgridOne Controller die u wilt bedienen.

MQTT Payload Structure

Opdrachten worden verzonden als JSON-payloads. De payloadstructuur is ontworpen om verschillende vermogensbeheerstrategieën en setpoints voor verschillende componenten van het smartgrid-systeem te specificeren. De volgende voorbeelden gebruiken fictieve identificatiegegevens en illustratieve limieten. Vervang de site-node-ID, tijdstempel en waarden door de waarden die bij uw installatie horen:

{
    "extraTags": {
        "nodeId": "DEMO_CONTROLLER_SiteA"
    },
    "time": 1791547200,
    "fields": {
        "storage_policy": "setpoint",
        "storage_power_setpoint_w": 5000,
        "site_policy": "limit",
        "site_import": 25000
    }
}

Beschrijving van de velden

• extraTags (Object):
  • nodeId (String): Een unieke identificatie voor de node binnen het netwerk van de SmartgridOne Controller's netwerk. Gebruik de werkelijke site-node-ID van de installatie. Deze kan verschillen van het serienummer gevolgd door '_site_0'; ga niet uit van dit achtervoegsel.
• time (Integer): Unix-tijdstempel in seconden die het tijdstip aangeeft waarop het bericht wordt verzonden.
• fields (Object):
  • <Component>_policy (String): Beleidstype voor de component. Als dit wordt weggelaten, kan een eerder groepsbeleid actief blijven tot de oorspronkelijke time-out. Gebruik een expliciete fallback-beleid om de besturing vrij te geven.
  • <Component>_power_setpoint_w (Float): Gewenste vermogenssetpoint in watt voor de component. Dit is optioneel en alleen relevant als een overeenkomstig beleid is opgegeven.

Componenten en beleidsregels

Elke component in het fields object kan een beleid en een instelpunt voor het vermogen bevatten. De volgende componenten kunnen worden bediend:

• solar_policy en solar_power_setpoint_w:

  • Regelt het beleid en instelpunt voor de opwekking van zonne-energie. Ondersteunde beleidsregels:
    • Policy setpoint: Stelt het maximale vermogen in dat door alle aangesloten zonne-installaties samen wordt geproduceerd. Het veld solar_power_setpoint_w moet worden ingesteld op de productievermogenslimiet in watt.
    • Policy feed-in-restriction: Produceert op vol vermogen, binnen de huidige netlimieten.
    • Policy cost: Schakelt kostenminimalisatie op basis van day-aheadprijzen (EPEX Spot-markt) voor de zonneproductie in. Bij negatieve injectieprijzen beperken we de productie tot het eigen verbruik. Wanneer zowel de afnameprijs als de injectieprijs negatief zijn, schakelen we alle zonne-installaties uit. Het veld solar_power_setpoint_w wordt genegeerd.
    • Policy off: Schakelt alle interactie met alle zonne-assets uit. Waarschuwing: limieten worden in deze modus niet bewaakt. Het veld solar_power_setpoint_w wordt genegeerd.

• storage_policy en storage_power_setpoint_w:

  • Regelt het beleid van het energieopslagsysteem en het laad- of ontlaadvermogen.
    • Policy setpoint: Stelt het totale laadvermogen (positief instelpunt) of ontlaadvermogen (negatief instelpunt) voor de groep batterijen in. Bij meerdere aangesloten batterijen wordt het instelpunt verdeeld op basis van het beschikbare laad- en ontlaadvermogen, zodat de batterijen gelijkmatig worden belast. Het veld storage_power_setpoint_w wordt ingesteld op het gewenste batterijvermogen.
    • Policy peak-shaving-only: Schakelt peak-shavingoptimalisatie voor de batterij in. Dit moet worden gecombineerd met vier peak-shavingparameters op siteniveau.
    • Policy cost: Schakelt kostenoptimalisatie op basis van day-aheadprijzen (EPEX Spot-markt) voor de batterijen in door ze tijdens goedkope uren op te laden en de energie tijdens dure uren te gebruiken. Het veld storage_power_setpoint_w wordt genegeerd.
    • Policy self-consumption: Schakelt een eenvoudig algoritme voor eigen verbruik op de batterijen in. Overtollige zonneproductie wordt overdag in de batterij opgeslagen en wanneer de zon onder is, wordt energie uit de batterij gebruikt. Het veld storage_power_setpoint_w wordt genegeerd.
    • Policy off: Schakelt alle interactie met alle batterij-assets uit. Waarschuwing: limieten worden in deze modus niet bewaakt. Het veld storage_power_setpoint_w wordt genegeerd.

• heat_pump_policy:

  • Schakelt warmtepompsystemen in of uit. De minimale en maximale inschakeltijden worden altijd gerespecteerd.
    • Policy cost: Schakelt kostenoptimalisatie op basis van day-aheadprijzen (EPEX Spot-markt) voor de warmtepompen in. Het lokale algoritme voor dynamische prijzen bepaalt de beste inschakelperioden.
    • Policy self-consumption: Schakelt de warmtepompen in wanneer er een overschot aan zonne-energie wordt geproduceerd.
    • Policy power_off: Schakelt de warmtepompen uit.
    • Policy power_on: Schakelt de warmtepompen in.

• switched_load_policy:

  • Schakelt relaisgestuurde systemen in of uit. Dit kan het ingebouwde relais of een via het netwerk aangesloten relais zijn.
    • Policy cost: Schakelt kostenoptimalisatie op basis van day-aheadprijzen (EPEX Spot-markt) voor het relais in.
    • Policy self-consumption: Schakelt het relais in wanneer er een overschot aan zonne-energie wordt geproduceerd.
    • Policy power_off
    • Policy power_on

• variable_power_load_policy en variable_power_load_power_setpoint_w:

  • Beheert het beleid en instelpunt voor het stroomverbruik van elektrische voertuigen.
    • Policy setpoint: Stelt het totale laadvermogen voor de groep EV's in. Het veld variable_power_load_power_setpoint_w wordt ingesteld op het gewenste laadvermogen.
    • Policy cost: Schakelt kostenoptimalisatie op basis van day-aheadprijzen (EPEX Spot-markt) voor de batterijen in door ze tijdens goedkope uren op te laden. Het veld variable_power_load_power_setpoint_w wordt genegeerd.
    • Policy self-consumption: Schakelt het opladen in wanneer er een overschot aan zonne-energie wordt geproduceerd. Het veld variable_power_load_power_setpoint_w wordt genegeerd.
    • Policy off: Schakelt alle interactie met alle EV-assets uit. Het veld variable_power_load_power_setpoint_w wordt genegeerd.

Power Limits

In plaats van bedieningsstrategieën en instelpunten in te stellen, kunnen ook vermogenslimieten voor opslag- en zonne-energieapparaten worden ingesteld.

Bijvoorbeeld:

{
    "extraTags": {
        "nodeId": "DEMO_CONTROLLER_SiteA"
    },
    "time": 1791547200,
    "fields": {
        "storage_policy": "limit",
        "storage_maxChargePower_W": 10000,
        "storage_maxDischargePower_W": 10000,
        "solar_policy": "limit",
        "solar_maxProductionPower_W": 15000
    }
}

Het veldvoorvoegsel is storage, solar of de node-ID van het betreffende apparaat. Neem het bijbehorende limit-beleid op wanneer u uitsluitend limietopdrachten verzendt, zoals hierboven. Limietwaarden in opdrachten zijn niet-negatieve grootheden: bijvoorbeeld storage_maxDischargePower_W: 10000 betekent een ontladingslimiet van 10 kW. Dit verschilt van feedback, waarin max_discharge_power_W negatief of nul is.

Site Control

De site kan afzonderlijk worden bediend. De volgende siteopdrachten kunnen naar de controller worden verzonden:

• default of fallback Actieve siteopdrachten verwijderen
• export De exportlimiet van de site instellen
• import De importlimiet van de site instellen
• setpoint Een site-instelpunt kan in beide richtingen maximaal 5% variëren
• setpoint_A Nog niet geïmplementeerd

De volgende variabelen zijn peak-shavingparameters en worden alleen toegepast wanneer de batterijstrategie is ingesteld op peak-shaving.

• startChargeBelow_W
• stopChargeAbove_W
• startDischargeAbove_W
• stopDischargeBelow_W

Een site-instelpunt is NIET compatibel met een import-/exportlimiet.

Bijvoorbeeld:

{
    "extraTags": {
        "nodeId": "DEMO_CONTROLLER_SiteA"
    },
    "time": 1791547200,
    "fields": {
        "storage_policy": "self-consumption",
        "site_policy": "limit",
        "site_export": 10000,
        "site_import": 25000
    }
}

Device Control

Specifieke apparaten kunnen ook worden bediend in plaats van apparaatgroepen op basis van hun type. Het bericht heeft dezelfde structuur:

• nodeId_policy en nodeId_power_setpoint_w

Fallbackgedrag

Het weglaten van een groepsbeleid annuleert de opdracht niet onmiddellijk: een eerder ontvangen groepsopdracht kan actief blijven tot de oorspronkelijk geconfigureerde time-out is verstreken. Gebruik een expliciete fallback-opdracht voor de groep of het apparaat wanneer u de bediening op afstand wilt vrijgeven. Apparaatspecifieke opdrachten worden niet bewaard in dezelfde cache voor groepsopdrachten; zie de onderstaande waarschuwing over lege opdrachten.

Als er helemaal geen opdracht wordt verzonden, worden na 60 seconden (of de geconfigureerde time-outperiode) de standaardbeleidsregels voor de assets opnieuw geactiveerd.

Bestaande opdrachten annuleren en terugvallen op lokale bedieningsmodi

Een actieve opdracht kan worden geannuleerd door een fallbackopdracht message.

Fallback Command

Een fallbackopdracht zal de bestaande opdracht cancelonmiddellijk annuleren en de immediately en de SmartgridOne Controller neemt de besturing van de installatie over. Het uitgevoerde beleid hangt af van wat is ingesteld in de SmartgridOne Controller Settings.

Dit kan ook worden gebruikt wanneer een secundair besturingssignaal, zoals een schema, als fallback wordt gebruikt.

Voorbeelden van berichten:

{
    "extraTags": {
        "nodeId": "DEMO_CONTROLLER_SiteA"
    },
    "time": 1791547200,
    "fields": {
        "storage_policy": "fallback"
    }
}

Empty Command

Een lege opdracht retourneert geaggregeerde feedback van de site, maar is geen alleen-lezenstatusaanvraag. De opdracht vervangt het laatst ontvangen bericht en kan eerdere apparaatspecifieke opdrachten verwijderen. Nog geldige groepsbeleidsregels kunnen opnieuw worden gebruikt totdat hun oorspronkelijke fallback-time-out verstrijkt. Gebruik dit niet als polling wanneer u verwacht dat de apparaatspecifieke bediening ongewijzigd blijft.

De lege opdracht heeft de volgende structuur:

{
    "extraTags": {
        "nodeId": "DEMO_CONTROLLER_SiteA"
    },
    "time": 1791547200,
    "fields": {}
}

Voorbeeldpayload

Hieronder staat een voorbeeld van een payload om verschillende beleidsregels en instelpunten in te stellen:

{
    "extraTags": {
        "nodeId": "DEMO_CONTROLLER_SiteA"
    },
    "time": 1714652046,
    "fields": {
        "solar_policy": "setpoint",
        "solar_power_setpoint_w": 5000,
        "storage_policy": "setpoint",
        "storage_power_setpoint_w": -5000
    }
}

In dit voorbeeld wordt de zonneproductie beperkt tot 5000 watt en vraagt het negatieve opslagsetpoint om 5000 watt ontlading. Een positief opslagsetpoint zou opladen aanvragen. Het weglaten van een groepsbeleid annuleert de eerdere opdracht niet noodzakelijk; gebruik een expliciet fallback-beleid wanneer u die groep wilt terugbrengen naar lokale bediening.

MQTT-documentatie voor het ontvangen van feedback

MQTT Feedback Topic

Abonneer u op het feedbacktopic om de status van de site en het resultaat van een verwerkte opdracht te lezen:

standard1/outbound/remoteControlMetrics/feedback/<Controller SN>

Vervang <Controller SN> door het serienummer van de controller. Het serienummer in het topic en de siteNodeId van de site zijn verschillende identificatiegegevens: gebruik altijd de werkelijke site-node-ID, die niet noodzakelijk eindigt op _site_0.

Wanneer feedback wordt verzonden

De standaardverbinding voor live bediening retourneert een statusmomentopname wanneer deze een opdracht accepteert en de verwerking van de bediening start. Dit bevestigt niet dat het fysieke apparaat het nieuwe setpoint al heeft bereikt.

Een lege opdracht met "fields": {} retourneert ook geaggregeerde status, maar is geen polling zonder bijwerkingen: de opdracht vervangt het laatste bericht en kan eerder gerichte apparaatspecifieke opdrachten verwijderen. Eerdere groepsbeleidsregels kunnen alleen actief blijven binnen hun oorspronkelijke fallback-time-out. Gebruik geen lege opdrachten om te pollen wanneer u verwacht dat de apparaatspecifieke bediening ongewijzigd blijft.

Sommige provider-specifieke MQTT-verbindingen publiceren ook ongeveer elke 30 seconden ongevraagde feedback. Deze periodieke publicatie is verbindingsspecifiek en geen gegarandeerd interval voor elke MQTT-integratie. Periodieke momentopnamen en antwoorden op lege opdrachten bevatten geen status van afzonderlijke apparaten.

Machineleesbare feedbackspecificatie

Gebruik het JSON Schema om feedbackpayloads te valideren, of het AsyncAPI-document om het feedbackkanaal van de controller te beschrijven. Beide beschrijven feedback, niet de volledige opdrachtinterface of provider-specifieke uitbreidingen.

Berichtomhulling

responseCode: 0 bewijst niet dat elk apparaat het aangevraagde setpoint heeft bereikt. Lees ook het gemeten vermogen, uitgevoerde setpoints, beperkingslabels en foutcodes van apparaten uit.

Succesvol antwoord

Deze illustratieve momentopname gebruikt fictieve identificatiegegevens en een bewust beperkte selectie metingen. Andere beschikbare velden worden hieronder beschreven.

{
  "time": 1791547201,
  "requestTime": 1791547200,
  "siteNodeId": "DEMO_CONTROLLER_SiteA",
  "fields": {},
  "data": {
    "responseCode": 0,
    "errors": "",
    "state": {
      "load": { "load_power_W": 12000 },
      "grid": { "active_power_W": 7000, "import_limit_W": 25000 },
      "storage": {
        "active_power_W": -5000,
        "mean_soc_perc": 60,
        "max_charge_power_W": 10000,
        "max_discharge_power_W": -10000,
        "dynamic_max_charge_power_W": 8000,
        "dynamic_max_discharge_power_W": -9000,
        "executed_power_W": -5000,
        "executed_policy": ["setpoint"],
        "errorCodes": {},
        "nr_devices": 1
      }
    }
  }
}

Foutantwoord

Probeer bij een verwerkingsfout niet data.state:

{
  "time": 1791547201,
  "requestTime": 1791547200,
  "siteNodeId": "DEMO_CONTROLLER_SiteA",
  "fields": {},
  "data": {
    "responseCode": 1,
    "error": "Command could not be processed"
  }
}

Geaggregeerde status lezen

De sectienamen zijn grid, load, storage, solar, heat_pump, switched_load en variable_power_load. Elke assetsectie combineert apparaten van dat type. Twee zonneapparaten met elk een capaciteit van 3 kW leveren bijvoorbeeld een geaggregeerde capaciteit van 6 kW.

solar en storage kan lege objecten zijn ({}) wanneer er geen overeenkomende apparaten zijn. De secties voor warmtepompen, geschakelde belastingen en belastingen met variabel vermogen behouden in dat geval nultellingen, lege arrays/maps en toepasselijke vermogenswaarden die null kunnen zijn.

Behandel een ontbrekend veld of nullpoortals niet beschikbaar, niet als nul. Veel metingen worden weggelaten wanneer ze onbekend zijn; sommige velden bevatten expliciet null. Een totaal kan alleen de apparaten bevatten waarvoor een waarde beschikbaar is. Leid niet uitsluitend uit nr_devices af dat alle metingen beschikbaar zijn.

De volgende algemene velden zijn van toepassing op storage, solar, heat_pump, switched_load en variable_power_load:

Net

Elke meting of limiet in state.grid is optioneel en wordt weggelaten wanneer deze onbekend is. Waarden zijn getallen; vermogen wordt uitgedrukt in watt, energie in wattuur en stroom in ampère.

Sitebelasting

state.load.load_power_W is een getal of null. Deze rapporteert ander verbruik op de site, exclusief afzonderlijk geregistreerd EV-laadverbruik en warmtepompverbruik. Dit is niet het totale siteverbruik en ook geen andere benaming voor netvermogen.

Opslag

Gebruik dynamic_max_charge_power_W en dynamic_max_discharge_power_W voor de huidige feedbackindeling. Deze vervangen de eerdere velden realised_charge_power_W en realised_discharge_power_W. Dynamische capaciteit is een schatting en geen garantie dat elk aangevraagd setpoint kan worden uitgevoerd; site- en apparaatbeperkingen blijven van toepassing.

Solar

Deze numerieke velden worden weggelaten wanneer ze niet beschikbaar zijn:

Warmtepompen

Geschakelde belastingen

EV-laders en belastingen met variabel vermogen

De sectie heet variable_power_load, niet variable_load.

Tellers voor laadenergie, stroomlimieten, ondersteuning voor pauzeren en laadsessies behoren tot afzonderlijke apparaten, niet tot deze aggregatiesectie.

Feedback van afzonderlijke apparaten

Om de status van een apparaat op te nemen, moet de opdracht het veld <nodeId>_policy bevatten en gericht zijn op een herkend apparaat. Een apparaatspecifiek setpoint op zichzelf vraagt geen feedback per apparaat op. Noch een lege opdracht, noch een periodieke momentopname bevat deze informatie.

De locatie is:

data.state.<section>.individual_devices.<nodeId>

Een opdracht die bijvoorbeeld zowel "DEMO_BATTERY_1_policy": "setpoint" en "DEMO_BATTERY_1_power_setpoint_w": -5000 bevat, kan dit fragment opleveren bij data.state.storage:

{
  "executed_policy": ["setpoint"],
  "errorCodes": {},
  "nr_devices": 1,
  "individual_devices": {
    "DEMO_BATTERY_1": {
      "active_power_W": -5000,
      "executed_power_W": -5000,
      "executed_policy": "setpoint",
      "constraint_ph0_label": null,
      "nr_devices": 1
    }
  }
}

Beleids-, modus- en beperkingsvelden per apparaat zijn enkele waarden, geen geaggregeerde lijsten. Onbekende metingen kunnen null zijn. De errorCodes van het apparaat is een array met fout-/statusitems en wordt alleen opgenomen wanneer dat apparaat items rapporteert; het is geen andere node-ID-map.

Afzonderlijke EV-velden

Een ingevuld object voor een laadsessie bevat:

Afzonderlijke VPP-verbindingen

vpp_id behoort tot een afzonderlijk geconfigureerde VPP-verbinding. Voeg dit niet toe aan de gewone live MQTT-configuratie of -opdrachten; de standaardfeedbackstatus vereist dit niet. Provider-specifieke toevoegingen mogen niet worden beschouwd als onderdeel van de algemene interface voor live bediening.

Storage Constraint Labels

De setpoints die door een extern signaal worden verzonden, kunnen intern door het EMS worden begrensd. De onderstaande tabel geeft een overzicht van mogelijke beperkingen voor het constraint_ph0_label feedbackveld.

MQTT Error Codes

Foutcodes zijn gegroepeerd in bereiken die de algemene categorie van het probleem aangeven:

De afzonderlijke foutcodes worden hieronder vermeld.

Verbindingsfouten (200)

Verbindingsproblemen tussen de EMS en het apparaat.

Antwoordfouten (300)

Het apparaat is verbonden, maar de antwoorden zijn ongeldig.

Regelfouten (600)

Meet- en setpointfouten (1000)

Ondersteunde MQTT-versies en gedrag bij onbevoegde topics

Bij het gebruik van MQTT is het belangrijk rekening te houden met de verschillen in de specificaties tussen versies 3.1, 3.1.1 en 5.0, met name met betrekking tot het gedrag van de broker wanneer clients publiceren naar onbevoegde topics.

Volgens de MQTT 3.1.1-specificatie (zie OASIS MQTT 3.1.1 Specification, sectie MQTT-3.3.5-2) moet een broker de verbinding beëindigen zodra een client een PUBLISH naar een topic verstuurt waarvoor deze geen toestemming heeft. Dit gedrag kan leiden tot onverwachte verbroken verbindingen voor clients die proberen te publiceren naar verkeerd geconfigureerde of onbevoegde topics.

In MQTT 3.1 bestaat deze vereiste niet. Wanneer een client met deze versie naar een onbevoegd topic publiceert, negeert de broker het bericht doorgaans (stille verwijdering) zonder de verbinding te beëindigen. Hierdoor is MQTT 3.1 in sommige gevallen geschikter wanneer robuustheid tegen configuratiefouten of tijdelijk ontbrekende rechten belangrijker is dan strikte beveiligingshandhaving.

Hoewel MQTT 5.0 de mogelijkheid introduceert om met redenencodes te werken (zoals PUBACK met een weigeringsreden), is hiervoor ondersteuning aan zowel client- als serverzijde vereist. Migratie naar MQTT 5.0 brengt daarom extra implementatie-inspanningen met zich mee.

Gevolgen van het negeren van compatibiliteit: Als een client verbinding maakt met MQTT 3.1.1 en probeert berichten naar onbevoegde topics te publiceren, zal de broker de sessie abrupt beëindigen. Dit kan leiden tot instabiliteit, verlies van connectiviteit of een hogere belasting door herhaalde pogingen om opnieuw verbinding te maken.

Recommended Approach: Voor systemen waarin clients mogelijk (tijdelijk) proberen te publiceren naar onbevoegde topics, of waarin foutafhandeling niet strikt is geïmplementeerd, raden we aan MQTT 3.1 te gebruiken. Dit zorgt voor stabielere verbindingen en voorkomt onbedoelde verbroken verbindingen tijdens runtime.