Changelog

Follow up on the latest improvements and updates.

RSS

We have added a new API and enhanced the "Reset Connectivity" feature on the Portal.
What's included in this release:
  • When users trigger "Reset Connectivity" via the Portal, it will no longer affect the Factory Test status. This means that the SIM status will remain in Factory Test Mode (previously, "Reset Connectivity" would exit FTM).
  • The "Reset Connectivity" process is now executed via a single API call, making it faster, especially for bulk resets across multiple devices. Previously, this action required four API calls: Endpoint Enable, Endpoint Disable, SIM Suspend, and SIM Activation.
  • Both Admin and User roles now have the permission to trigger "Reset Connectivity" via the Portal (previously, only the Admin role had this access).
Tip:
Use "Reset Connectivity" to immediately apply updates made under the Service and Coverage Policy to all devices associated with that policy.
Please check API Docs if you have any questions.
Screenshot 2024-10-21 at 14
Herewith we announce the deprecation of the Quota with Throttling functionality. New devices should not be configured with Quota with Throttling, but Quota with Blocking should be used instead. Similarly, existing devices should be reconfigured to use Quota with Blocking.
Existing devices can continue using Quota with Throttling functionality with the current SLAs until December 31st, 2024.
After October 31st, 2024, we will remove the functionality from the Portal and API.
On December 31st, 2024, we will convert all Service Policies that still use Quota with Throttling to the Quota with blocking feature.
No data connectivity interruption will occur at any stage of the process.
We announce hereby the decommissioning of TCP as transport protocol for OpenVPN connections by 1st of October 2024 and solely support UDP. The goal is to reduce the complexity of our service and simplify operations, while TCP as OpenVPN transport layer does not bring any effective benefits in terms of data connectivity performance. On the contrary, it may produce head of line blocking and get particularly inefficient when transporting a TCP based application (see also https://openvpn.net/faq/what-is-tcp-meltdown/). In order to achieve reliability at the application layer, it is enough if the application itself uses TCP transport (e.g. http, https, ftp, ssh).
Please contact our support in case your Internet service provider blocks UDP traffic, which would then prevent you from establishing OpenVPN connections with our platform over UDP and hence make TCP the only viable alternative (see also https://openvpn.net/faq/why-does-openvpn-use-udp-and-tcp/).
Since the beginning of 2024, we have been collaborating with customers through an evaluation program to trial our converged cellular and satellite services. More than 20 evaluators have tested the solution, shared valuable feedback, and are now offering enhanced services to their customers who need reliable coverage in remote areas.
We are excited to announce that our converged cellular and satellite solutions are now generally available to all customers through our SATPlus (combined cellular and satellite), SATSolo (satellite only), and CellSolo data plans.
For more details on our satellite offerings, please refer to our documentation: https://docs.emnify.com/services/iot-supernetwork-satellite.
If you'd like to test any of our satellite products, we recommend opening a separate test account in the portal and ordering a Satellite eSIM from there. You'll receive a complimentary $10/€10 credit for testing. To upgrade to a production account, please contact your customer success manager.
Interested in learning about the portal features designed to help you better manage satellite connectivity? Find out more here: https://docs.emnify.com/how-tos/manage-satellite-connectivity.
image
emnify is planning to optimize the selection criteria for the automatic breakout region, taking advantage of the newly available regions eu-central-1 (Frankfurt) and eu-central-2 (Zurich) and the resulting inter-regional latency measurements.
The change will be rolled out starting with September 30th, 2024.
As a result, customers who configured the “Automatic breakout region” in the Service Policy will observe lower latencies on the data path due to the data traffic being shifted to a closer geographical location.
No interruption is expected, because data sessions will migrate to the newly assigned regions as they are being recreated by the devices.
However, customers who implement IP address filtering on the backend / application must be aware that the public IP addresses of the device may change and therefore may get blocked. To prevent this from happening, the firewall rules must be updated to include all the public IP address used by emnify, as documented here: https://support.emnify.com/hc/en-us/articles/4417775717010-List-of-emnify-s-public-IPs. The most frequent migration will be from eu-west-1 (Ireland) to eu-central-1 (Frankfurt).
The breakout region used by a particular device can be quickly identified in the portal:
breakout_region_and_Gi
The selection mechanism for the automatic breakout region may be overridden by explicitly configuring a region in the Service Policy (instead of the automatic breakout region).
We have released Reworked SIM inventory Interface.
What is included into the release:
  • Reworked Interface: added SIM status column and moved ICCID and MSISDN columns to the first place;
  • Now users can open details by clicking on any raw at any place;
  • In SIM details we maid it easier to copy any ID number by hovering it and removed unused fields of information;
Please check Product Docs if you have any questions.
In the following months we will keep updating SIM inventory providing new features for SIM management and filtering
Screenshot 2024-08-15 at 16
Screenshot 2024-08-15 at 16
Screenshot 2024-07-15 at 12
We have started a staged release of Reworked Service Policy.
What is included into the release:
  • We reworked whole Interface of Service Policy.
  • Now users can set Data limits and Thresholds to any custom value. When custom threshold is reached there should be an event created in event log.
We are deploying new functionality in a few steps. During next 20-30 days Reworked Service Policy will be available for all clients.
Please check Product Docs if you have any questions.
What's New?
Previously, you could only block Operators and also RAT types at the device level. With this new API, you now have the capability to apply these blocks at the Coverage Policy level, which means you can manage groups of devices more efficiently.
1. Prevent Device Malfunctions:
Avoid connectivity issues by blocking operators that are down or not functioning properly, and/or restricting RAT types that experience problems on a specific operator. This new feature helps maintain stable network connections.
2. Enhanced Control over Coverage:
Optimize your devices data usage by blocking operators in countries where you don't want them to function. This allows you to manage your connectivity budget and upsell new countries access to your IoT devices users.
We will add Portal functionality next step. Let us know by leaving a LIKE under this post if you want to be the first to test it.
Check API documentation here:
We would like to announce some changes to our network coverage in Bolivia and Panama.
Network added to the the emnify coverage:
Bolivia - Entel
New Coverage Area:
Global Extended - Zone I; Global Basic - Zone B; Regional Pro - Americas;
Network removed from the emnify coverage:
Panama - Digicel
Current Coverage Area:
Global Extended - Zone I; Global Basic - Zone B; Regional Pro - Americas
New coverage area:
None

new

User Interface

API

IP address management updates

As part of a larger overhaul of the IP address space management, emnify has rolled out the following updates:
Load More