Je IoT Core-abonnement (welke edition je ook hebt) komt met een basic resource pack: een maandelijkse quota die gedeeld wordt tussen gewone API-calls (zoals getstatus(), getproperties() die de plugin gebruikt) én de message service (Pulsar). Die allowance verschilt per abonnementsplan en wordt elke maand ververst, niet-gebruikte resources worden niet meegenomen naar de volgende maand, en je wordt pas gefactureerd zodra je verbruik boven de maandelijkse allowance uitkomt.
Standaard wordt die gedeelde pool voor referentiedoeleinden zo verdeeld: een gelijke verdeling van de allowance, waarbij 50% is gereserveerd voor API-calls en de andere 50% voor de message service. Dus elk Pulsar-bericht dat je ontvangt (elke deur-open/dicht-melding) telt mee in diezelfde pool als je gewone poll-aanroepen, niet als iets aparts.
De IoT Core Trial-versie is tot 6 maanden gratis aan te vragen, en na afloop kun je gewoon een verlenging aanvragen; overschrijd je de maandelijkse gratis quota, dan wordt de toegang beperkt totdat de volgende maand de quota ververst, of je een geavanceerdere IoT Core-versie aanschaft.
De consumptie tot nu toe vindt je via (nadat je ingelogd bent op het Tuya developer platform) Cloud -> Usage:
Authorization Token Management
Is de dienst die de authenticatie-laag onder al je andere API-calls verzorgt: hij levert de API’s waarmee je jouw Access ID/Access Secret (de sleutels die je toch al in de plugin invult bij “Username”/”Password”) omwisselt voor een tijdelijk toegangstoken, en waarmee je dat token ververst zodra het verloopt, elk OAuth-token is namelijk maar 2 uur geldig, waarna een refresh-call nodig is om verder te kunnen werken.
Dit is geen aparte functie die je zelf aanroept, elke keer dat de plugin (of TinyTuya eronder) een API-call doet, gebeurt er eerst impliciet een token-aanvraag of -refresh via deze dienst. Bij 8 apparaten, meerdere pollcycli per uur, én nu ook de Pulsar-verbinding die af en toe herauthenticeert, loopt dit vanzelf aardig op als apart geteld item in je statistieken.
Kost dit apart quota? Nee, dit hoort bij de basisdienstverlening van IoT Core en wordt niet los in rekening gebracht bovenop je gewone API/message-quota; het is puur de “motor” die alle andere calls draaiende houdt, geen extra verbruikspost om je zorgen over te maken.
Message Subscriptions service, Device Bind Count en Controllable Device Bind Count
Message Subscriptions: Het beheren van de message-service zelf (subscriptions aanmaken/opvragen/monitoren), apart van de eigenlijke berichten die je ontvangt
Device Bind Count en Controllable Device Bind Count zijn geen aparte API-diensten zoals Authorization Token Management, het zijn quotalimieten van je project zelf, uit de Pricing-documentatie:
Device Bind Count: het maximale aantal apparaten dat je aan het project mag koppelen om hun data te kunnen volgen/uitlezen. Elk apparaat dat je koppelt telt hiertegen mee.
Controllable Device Bind Count:het maximale aantal apparaten dat je via API-calls mag aansturen (dus niet alleen uitlezen, maar ook actief bedienen/statuswijziging pushen). Het aansturen van elk apparaat verbruikt één eenheid uit deze aparte quota, los van het gewone “aantal gekoppelde devices”-limiet.
Local IP-rescan interval
Dit kost geen Tuya-credits! tinytuya.deviceScan() die gebruikt wordt is een pure lokale UDP-broadcast over je eigen LAN. Er wordt geen Tuya cloud-API aangeroepen. Deze instelling heeft dus geen enkele invloed op je resource-verbruik. In een statische omgeving (geen nieuwe Tuya-apparaten, vaste IP’s) dient hij alleen om lokale IP-adreswijzigingen (bijv. na een router-reboot) bij te werken. Je kunt hem rustig ruim zetten, bijvoorbeeld 6 uur. Puur om onnodige lokale netwerk-chatter en loggruis te beperken, niet vanwege credits. Heb je géén vaste DHCP-reservering voor je Tuya-apparaten, houd ‘m dan liever dichter bij 1-2 uur, anders lopen lokale polls voor een tijdje mis na een IP-wissel.
API Polling Interval
Dit ís de echte credit-hendel! Elke cyclus kost ruwweg 1 getstatus() cloudcall per apparaat (plus wat overhead). Bij 30 minuten en 8 apparaten is dat 48 cycli/dag × 8 = ~384 cloud-calls/dag. Heb je bijvoorbeeld 17 apparaten zelfs ~816 calls/dag. Nu je deurcontacten én de motion sensor al realtime via Pulsar (fast path) bijgewerkt worden (zonder deze cyclus nodig te hebben) dient deze cloud-poll voor die apparaten alleen nog als vangnet (voor het zeldzame gemiste pushbericht), terwijl hij voor de rest (schakelaars, lampen, kWh-meters) nog steeds de enige manier is om bijgewerkt te blijven.
Heb je een omgeving die statische is (er komen geen devices bij) en waar lage credit-consumptie voorop staat, is een goede afweging: 4-6 uur. Dat brengt het aantal cycli naar 4-6 per dag terwijl schakelaars/lampen nog steeds binnen een halve werkdag verse data krijgen, en je deurcontacten/motion sensor sowieso al binnen seconden bijgewerkt blijven via Pulsar, onafhankelijk van deze instelling.
Qua consumptie letten op …
Met een handvol deurcontacten en een motion sensor die alleen bij daadwerkelijke gebeurtenissen pushen (geen continue polling meer via Pulsar zelf, de fast path doet zelfs geen extra API-call per event), is het berichtenverbruik van de message service zelf heel laag. De grootste bijdrage aan je quotaverbruik komt waarschijnlijk nog steeds van de reguliere polling (lokale/cloud pollcycli die de plugin sowieso al deed, los van deze Pulsar-toevoeging).