start () print ( "Connected to ZDM" ) while True : sleep ( 5000 ) start () except Exception as e : raise e print ( "Connected to Wi-FI" ) # Configure and start ZDM Agent. next_expansion ( relay, ( 1 ,)) # Configure and connect to the Wi-Fi network.
# In this demo the arrow on the rotary switch points to the 1. OUT1 ) else : print ( "Unknown state" ) # Initialize the board and relay expansion by providing the position of the rotary switch. def relay_handler ( agent, args ): print ( "Job request received!", args ) if args = "on" : exp_relay. After that, all we need to do is initialize all the necessary stuff and assign the handler.įrom bsp import board from zdm import zdm from expansions import relay from networking import wifi SSID = "MY NETWORK SSID", PASS = "MY NETWORK PASS" # Relay handler. Inside that handler, based on the job argument, we will turn a relay on or off. Don't forget to prepare your device, for the ZDM, as a preliminary step - you can follow the instructions on this page to do this.įirst, we will create the handler function which will be called when a particular job operation on the ZDM is triggered. In this demo we will create a simple application which will just set the relay state based on jobs gathered from ZDM. This tutorial is based on the Control Industrial Lamp with EXP-RELAY, Please refer to it if you have questions on the hardware. You can find more information about ZDM Jobs on this page and details about the API on this page. On the device side, the library is simple and easy to use. On the ZCloud side, the interface is pretty simple and adjustable. From the operator’s point of view, you can control devices at scale, while issuing jobs and executing functions in a schedulable manner for a large fleet of devices. ZDM Jobs are functions that are triggered on the zCloud and executed on the respective devices. ZDM Jobs are probably the easiest way to handle actuators by using the zCloud and ZSDK.
Zcloud codes update#
And another option is that you can update the firmware to fix bugs. Or you have the ability to shutdown the system before a failure occurs. In contrast to an IoT enabled Water pump, you get periodic diagnostics of the operations and can issue remote procedure calls that can be preconfigured to fix a critical situation. To determine the cause for failure then, the technicians have to travel on-site to fix the failure. If these pumps fail, catastrophic events could happen and, perhaps, what’s worse is that for the technicians, there is no way to know when, why or how this failure occurred. They cannot be monitored remotely and don’t provide any feedback with respect to on-going operations. Water pipes are traditionally controlled by legacy pumps that require on-site maintenance.
Boards and Expansions Boards and Expansions.Technical Reference Technical Reference.Fleet Actions: Firmware over the air updates.Controlling Relays with Jobs in zCloud Controlling Relays with Jobs in zCloud Table of contents.ZM1-DB and Expansion boards ZM1-DB and Expansion boards.Tutorials and Demos Tutorials and Demos.