Bu sayfa henüz yerel dilinizde mevcut değildir. Daha fazla dil seçeneği eklemek için yoğun bir şekilde çalışıyoruz. Desteğiniz için teşekkür ederiz.
- What's New
- Product Bulletin
- Service Overview
- Billing
-
Getting Started
-
Quick Device Access - Property Reporting and Command Receiving
- Subscribing to IoTDA
- Connecting a Smart Smoke Detector to the Platform (Quick Usage)
- Registering a Simulated Smart Street Light Device
- Using MQTT.fx to Simulate Communication Between the Smart Street Light and the Platform
- Using a Virtual Smart Street Light to Communicate with the Platform (Java SDK)
- Using a Virtual Smart Street Light to Communicate with the Platform (C SDK)
- Quick Device Access - Message Sending and Receiving
- Quick Application Access
-
Quick Device Access - Property Reporting and Command Receiving
-
User Guide
- Overview
- IoTDA Instances
- Resource Spaces
- Device Access
- Message Communications
- Device Management
-
Rules
- Overview
- Data Forwarding Process
- SQL Statements
- Connectivity Tests
- Data Forwarding to Huawei Cloud Services
- Data Forwarding to Third-Party Applications
- Data Forwarding Channel Details
- Data Forwarding Stack Policies
- Data Forwarding Flow Control Policies
- Abnormal Data Target
- Device Linkage
- Monitoring and O&M
- Granting Permissions Using IAM
-
Best Practices
- Introduction
-
Device Access
- Developing an MQTT-based Simulated Smart Street Light Online
- Developing a Smart Street Light Using NB-IoT BearPi
- Developing a Smart Smoke Detector Using NB-IoT BearPi
- Connecting and Debugging an NB-IoT Smart Street Light Using a Simulator
- Developing a Protocol Conversion Gateway for Access of Generic-Protocol Devices
- Connecting a Device That Uses the X.509 Certificate Based on MQTT.fx
- Connecting to IoTDA Based on the BearPi-HM_Nano Development Board and OpenHarmony 3.0
- Testing MQTT Performance Using JMeter
- Device Management
- Data Forwarding
- Device Linkage
-
Developer Guide
- Before You Start
- Obtaining Resources
- Product Development
- Development on the Device Side
- Development on the Application Side
-
API Reference
-
API Reference on the Application Side
- Before You Start
- Calling APIs
- API Overview
-
API
- Product Management
- Device Management
- Device Message
- Device Command APIs
- Device Property
- AMQP Queue Management
- Access Credential Management
- Data Forwarding Rule Management
-
Transition Data
- Push a Device Status Change Notification
- Push a Device Property Reporting Notification
- Push a Device Message Status Change Notification
- Push a Batch Task Status Change Notification
- Push a Device Message Reporting Notification
- Push a Device Addition Notification
- Push a Device Update Notification
- Push a Device Deletion Notification
- Push a Product Addition Notification
- Push a Product Update Notification
- Push a Product Deletion Notification
- Push an Asynchronous Device Command Status Change Notification
- Rule Management
- Device Shadow
- Group Management
- Tag Management
- Instance Management
- Resource Space Management
- Batch Task
- Device CA Certificate Management
- OTA Upgrade Package Management
- Message Broadcasting
- Device Tunnel Management
- Stack policy management
- Flow control policy management
- Device Proxy
- Device Policy Management
- Bridge Management
- Pre-provisioning Template Management
- Custom Authentication
- Codec Function Management
- Permissions and Supported Actions
- Examples
- Appendix
-
MQTT or MQTTS API Reference on the Device Side
- Before You Start
- Communication Modes
- Topics
- Device Connection Authentication
- Device Commands
- Device Messages
- Device Properties
-
Gateway and Child Device Management
- Platform Notifying a Gateway of New Child Device Connection
- Platform Notifying a Gateway of Child Device Deletion
- Gateway Synchronizing Child Device Information
- Gateway Updating Child Device Status
- Responding to a Request for Updating Child Device Statuses
- Gateway Requesting for Adding Child Devices
- Platform Responding to a Request for Adding Child Devices
- Gateway Requesting for Deleting Child Devices
- Platform Responding to a Request for Deleting Child Devices
- Software and Firmware Upgrade
- File Upload and Download
- Device Time Synchronization
- Device Reporting Information
- Device Log Collection
- Remote Configuration
- Device Tunnel Management
- HTTPS API Reference on the Device Side
- LwM2M API Reference on the Device Side
- Security Tunnel WebSocket API Reference
- Module AT Command Reference
- Change History
-
API Reference on the Application Side
- SDK Reference
-
FAQs
- Top FAQs
-
Solution Consulting
- In What Scenarios Can the IoT Platform Be Applied?
- What Are the Changes Brought by the Integration of IoT Device Management and IoTDA?
- Can I Enable IoTDA for IAM Users or Sub-Projects?
- Which Regions of Huawei Cloud Are Supported by the IoT Platform?
- Does Huawei Provide Modules, Hardware Devices, and Application Software?
- What Should I Do If I Want to Call an API But Have No Permissions to Do So as an IAM User? (Is It Edition-specific?)
- Why Was I Prompted to Grant Security Administrator Permissions When I Create a Rule or Set Resource File Storage?
- Which Resource Space Will Be Set As Default on the IoT Platform?
- How Does IoTDA Obtain Device Data?
- Is There Any Limitation on the Number of Resource Spaces and Devices I Can Add on the IoT Platform?
- Does the IoTDA Support Device Registration in Batches?
- Are There Any Limitations on the Use of the IoT Platform?
- What DTLS Encryption Algorithms Are Supported by the IoT Platform?
- Does the IoT Platform Support Conversion Between Big-Endian and Little-Endian for Binary Data?
- What Is NB-IoT?
- What Are the Components of the IoT Platform and What Hardware Architectures Does It Support?
- How Do I Obtain the Platform Access Address?
- Device Integration
- IoT Device SDKs
- LwM2M/CoAP Device Access
- MQTT-based Device Access
- Products Models
- Message Communications
- Subscription and Push
- Codecs
- OTA Upgrades
- Application Integration
- General Reference
Copied.
Pay-per-Use Billing
Pay-per-use billing is a postpaid mode in which you pay for what you use. This billing mode requires no upfront or long-term commitments. This section describes the billing rules for pay-per-use IoTDA resources.
Scenario
Pay-per-use is suitable for applications or services that cannot be interrupted when facing temporary or sudden traffic increases or unpredictable demands, such as e-commerce flash sales, testing, and scientific computing.
Billing Items
You are billed for the following resources on a pay-per-use basis.
Billing Item |
Description |
---|---|
Standard instance |
Billed by instance specifications and usage duration |
Billing Method
The usage of pay-per-use IoTDA resources is billed on a daily basis. If a resource is used for less than a full day, the fee is calculated based on the actual duration of usage. Billing is settled at 00:00 every day (UTC+08:00), and a new billing cycle begins thereafter. The billing starts from the time when the standard instance is successfully created and ends at the time when the instance is deleted.
Billing Examples
Assume you subscribed to a standard SU1 instance at 09:59:30 on April 18, 2023 and then deleted it at 11:45:46 on April 20, 2023.
- The first billing cycle spans from April 18, 2023, 00:00:00 to April 19, 2023, 00:00:00. Fees are incurred from April 18, 2023, 09:59:30 to April 19, 2023, 00:00:00, resulting in a billing duration of 50,400 seconds.
- The second billing cycle spans from April 19, 2023, 00:00:00 to April 20, 2023, 00:00:00. Fees are incurred throughout this period, resulting in a billing duration of 86,400 seconds.
- The third billing cycle spans from April 20, 2023, 00:00:00 to April 21, 2023, 00:00:00. Fees are incurred from April 20, 2023, 00:00:00 to April 20, 2023, 11:45:46, resulting in a billing duration of 42,346 seconds.
You need to pay for each billing cycle. Table 2 lists the billing formula. The pricing details show the daily cost of a resource, which can be converted to the cost per second by dividing the daily price by 86,400.
Resource |
Formula |
Unit Price |
---|---|---|
IoTDA standard instance |
Unit price x Unit quantity x Purchase duration |
To make a purchase, please refer to the IoTDA Price Calculator and select the desired unit type. By default, the number of units is set to 1 and the duration is set to one day. The configuration fee displayed at the bottom of the page represents the daily price of the instance. |
Impact on Billing After Specifications Change
If you change the specifications of a pay-per-use instance, the original order will become invalid and a new order will be placed. You will be billed based on the new specifications.
If you change the instance configuration within one day after the purchase, the billing cycle information is generated based on the new configuration.
For example, if you subscribed to a standard SU1 unit at 09:00:00 on April 18, 2023 and upgraded it to a SU2 unit at 09:30:00 on April 18, 2023, two billing records are generated in the billing cycle on that day.
- The first record corresponds to the period from April 18, 2023 09:00:00 to April 18, 2023 9:30:00. The instance specifications are charged based on one SU1.
- The second record corresponds to the period from April 18, 2023 09:30:00 to April 19, 2023 00:00:00. The instance specifications are billed based on one SU2 unit.
A standard instance can be configured with multiple units of the same type, for example, five SU1 units, but cannot be configured with different types of units, for example, two SU1 units and three SU2 units. You can change the number and type of units at any time. For example, you can upgrade two SU1 units to five SU1 units or two SU1 units to two SU2 units. A free SUF unit can be upgraded to an SU1, SU2, SU3, or SU4 unit. After the upgrade, the original SUF unit is no longer retained.
Impact of Arrears
Figure 1 shows the statuses a pay-per-use IoTDA instance can have throughout its lifecycle. After an IoTDA instance is purchased, it enters the valid period and runs normally during this period. If your account goes into arrears, the IoTDA instance enters a grace period and then a retention period.
- The system deducts fees from your account balance for pay-per-use resources at the end of each billing cycle. When your account is in arrears, you will be notified by email, SMS, and internal message.
- Impact of arrears
- If your account is insufficient to pay your amount, your account goes into arrears. However, your resources will not be stopped immediately; instead, they enter the grace period. You are still responsible for fees incurred during the grace period. You can view the charges on the Billing Center > Overview page and pay any past due balances as needed. Huawei Cloud will automatically deduct this amount when you top up.
- If you do not pay the arrears within the grace period, your resources will enter the retention period and become frozen. You cannot perform any operations on the pay-per-use resources during this period.
- If you do not bring your account balance current before the retention period ends, your resource will be released and the data cannot be restored.
- Both the grace period and retention period for Huawei Cloud International are 15 days.
- For details about top-up, see Top-Up and Repayment.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot