egeoffrey-sdk v1.1 released

  • A significant change has taken place in the new egeoffrey-sdk version 1.1, even if completely transparent for the end user.

    In all previous version of the SDK, modules were expecting to find the entire configuration pinned (retained) on the message bus. This was perfectly fine for a local gateway but was causing a few issues to the Cloud Gateway (when in use) because the whole configuration was supposed to be kept in memory and data of house no more in use would have been kept there forever, making the service not really scalable. Additionally, there was too much complexity for controller/config to reconcile the local configuration with the one already pushed.

    With version 1.1, there is an option for configuration to be no more pinned on the gateway but controller/config will send it over to every module requesting it. This is once again completely transparent for the user since the underlying SDK will take care of handling the entire process.

    The behaviour is controller by the new global variable EGEOFFREY_GATEWAY_VERSION (which superceed the static API_VERSION). This gateway protocol version is used to allow modules to communicate each other in the same way. If set to "1", the old communication mechanism is used (configuration and messages retained in the bus), if set to "2", the new one is used.
    Technical details about the design of this capability and the changes are available at

    To ensure backwards compatibility, default gateway protocol version will be v1 for existing deployments, v2 for the new ones. Of course all the modules connecting to the same gateway should be configured with the same protocol for communication to take place, packages must be built against SDK >= v1.1 (rebuild process is underway), egeoffrey-controller must be version >= 1.4.

    An updated version of egeoffrey-gui (v1.4) is also about to be released to support this capability. Upon login, the user can now select between v1 and v2 gateway protocol version.

    Once again, nothing changes for both end users and developers since those changes are handled entirely by and within the SDK.

    A couple of small bugs have been fixed as well, which were causing a huge CPU consumption when a package was started, which was particularly critical when many packages are started altogether (like when running egeoffrey-cli start).

    To leverage this capability, update your eGeoffrey deployment by running:

    • egeoffrey-cli update to update all the packages with those built against SDK v1.1
    • egeoffrey-cli set_env EGEOFFREY_GATEWAY_VERSION 2 to set gateway protocol version to v2
    • egeoffrey-cli restart to restart eGeoffrey and apply the changes
    • egeoffrey-cli logs_tail to review everything is working correctly and that the packages are using v2 gateway protocol under "Environment settings"


  • All eGeoffrey packages have been now upgraded to use SDK v1.1 (see above for instructions on how to update).

    egeoffrey-cli has been also updated to use gateway protocol v2 when using the Cloud Gateway, v1 for local deployments.

    For the few users using collections packages (which is not the default), please note package egeoffrey-notification-chromecast have been moved from egeoffrey-collection-raspberrypi to egeoffrey-collection-core due to conflicts with the dependencies so notification/chromecast should be moved by manually editing the configuration file.

    What's next? Support for Python3 of course!

Log in to reply