This is the source repository for the Python components related to my Programming the Internet of Things book and Connected Devices IoT course. These are shell wrappers ONLY and are not a solution set (which is a separately repository, not yet released). For convenience to the reader, some basic functionality has already been implemented (such as much of the application [ConstrainedDeviceApp.py], the configuration logic, consts, interfaces, and test cases).
Important notes on coding conventions in this repository:
- Use of 'interfaces' (modules and classes beginning with 'I' followed by their proper name [e.g., IDataManager]):
- Python doesn't have 'interfaces'. In keeping with the OO-related design concepts of all code throughout my book and discussed in my class, along with my goal of maintaining design and naming parity between the CDA (Python) and GDA (Java), I chose to declare 'interface' modules and classes for the CDA (which follow the same convention built into the GDA's Java repository). While they largely serve no functional purpose, I find the explicit definition of 'interfaces' helpful in terms of describing expected derived type contracts. In Python, these classes are essentially treated as empty concrete 'base' classes. They're not necessary functionally, but are helpful when teaching OO design concepts in my course.
- Naming conventions:
- Some of my naming conventions may not be considered 'Pythonic'. Where feasible, however, I do my best to follow the guidelines ('guidelines', not 'requirements') specified in PEP-0008, and remain consistent with my conventions throughout the code base. Examples:
- Module names: I use CapWords for most module names. I find this easier to read* - partly because I'm accustomed to it. It's also easier for teaching when comparing functionality between the CDA and GDA. The exception within the CDA is for test cases, where the module name begins with 'test_' followed by the CapWords module name.
- Class names: I use CapWords.
- Function names: I use camelCase. Again, I find this easier to read* vs the convention that uses underscores to separate words.
- Variable names: These follow the same convention as function names, again, for readability*.
- *I recognize that the concept of 'readability' may be somewhat subjective.
- Some of my naming conventions may not be considered 'Pythonic'. Where feasible, however, I do my best to follow the guidelines ('guidelines', not 'requirements') specified in PEP-0008, and remain consistent with my conventions throughout the code base. Examples:
- Tests:
- The test path (tests) has two sub-directories - one for 'unit' tests, one for 'integration' tests. For the short term, th means that the path hierarchy differs slightly from the main source tree (under 'piot') due to the inclusion of 'unit' and 'integration' as parent paths for what is essentially a shared path convention as the main source tree. This allows the user to run all unit tests (and only unit tests) without bothering with setup and configuration for external components often necessary to run the integration tests.
- Final notes:
- The code in this repository is largely comprised of shell classes that are designed to be implemented by the reader and are NOT solutions. These shell classes and their relationships respresent a notional design that aligns with the requirements listed in Programming the IoT Requirements. These requirements encapsulate the programming exercises presented in my book Programming the Internet of Things: An Introduction to Building Integrated, Device to Cloud IoT Solutions.
Please see the following links to access exercises, errata / clarifications, and the e-book:
If you're reading Programming the Internet of Things: An Introduction to Building Integrated, Device to Cloud IoT Solutions, you'll see a tie-in with the exercises described in each chapter and this repository. Most of the code in the main src tree is NOT implemented by design. It's intended for you - as the reader of my book (and possibly a student in one of my IoT courses) - to implement by filling in the implementation details as you work through each exercise.
A solution set is available, although I haven't yet released it. Stay tuned for updates on this topic.
These components are all written in Python3, and correlate to the exercises designed for the Constrained Device Application (CDA) specified in my book Programming the Internet of Things: An Introduction to Building Integrated, Device to Cloud IoT Solutions.
Since Python is also used for various cloud computing activities, there are other components that may be introduced as Cloud Service Functions (CSF) in the future, as they will share some of the common data management code written for the CDA exercises.
This repository is comprised of the following top level paths:
- config: Contains basic configuration file(s).
- piot: The top level of the 'Programming the IoT, or piot' project source code.
- tests: The top level of the 'Programming the IoT, or piot' project tests.
- unit: The unit test source tree for cda-python-components.
- integration: The integration test source tree for cda-python-components.
- simTestData: Contains sample simulated test data.
- This simulated test data was generated as part of my own solution to Lab Module 5 as part of the exercises referenced above. Keep in mind that these data are from my own solution, which will likely be different from your own.
Here are some other files at the top level that are important to review:
- requirements.txt: The core library dependencies - use pip to install.
- requirements_cv.txt: The optional CV library dependencies - STILL BEING TESTED - use pip to install.
- README.md: This README.
- LICENSE: The repository's LICENSE file.
Lastly, here are some 'dot' ('.{filename}') files pertaining to dev environment setup that you may find useful (or not - if so, just delete them after cloning the repo):
- .gitignore: The obligatory .gitignore that you should probably keep in place, with any additions that are relevant for your own cloned instance.
- .vscode: The VS Code project configuration file directory (useful if you're using VS Code as your IDE).
- launch.json: The default VS Code project debug launch configuration that may / may not be useful for your own cloned instance.
- settings.json: The default VS Code project customizations configuration that may / may not be useful for your own cloned instance.
- .project: The default Eclipse IDE project configuration file that may / may not be useful for your own cloned instance. Note that using this file to help create your Eclipse IDE project will result in the project name 'piot-cda-python-components' (which can be changed, of course).
- .pydevproject: The default Eclipse IDE and PyDev-specific configuration file for your Python environment that may / may not be useful for your own cloned instance.
NOTE: The directory structure and all files are subject to change based on feedback I receive from readers of my book and students in my IoT class, as well as improvements I find to be helpful for overall repo betterment.
PR's are disabled while the codebase is being developed.
Much of this repository, and in particular unit and integration tests, will continue to evolve, so please check back regularly for potential updates. Please note that API changes can - and likely will - occur at any time.
This repository has external dependencies on other open source projects. I'm grateful to the open source community and authors / maintainers of the following libraries:
Lab Module Library References (not all are required for each lab module):
- aiocoap
- Reference: Amsüss, Christian and Wasilak, Maciej. aiocoap: Python CoAP Library. Energy Harvesting Solutions, 2013–. http://github.com/chrysn/aiocoap/.
- apscheduler
- Reference: A. Grönholm. APScheduler. (2020) [Online]. Available: https://pypi.org/project/APScheduler/.
- psutil
- Reference: G. Rodola. Psutil. (2009 – 2020) [Online]. Available: https://psutil.readthedocs.io/en/latest/.
- numpy
- Reference: NumPy. NumPy. (2020) [Online]. Available: https://numpy.org/.
- matplotlib
- Sense-Emu
- Reference: The Raspberry Pi Foundation. Sense HAT Emulator. (2016) [Online]. Available: https://sense-emu.readthedocs.io/en/v1.0/.
- pisense
- Reference: D. Jones. Pisense. (2016 – 2018) [Online]. Available: https://pisense.readthedocs.io/en/release-0.2/.
- paho-mqtt
- Reference: Eclipse Foundation, Inc. Eclipse Paho™ MQTT Python Client. (2020) [Online]. Available: https://github.com/eclipse/paho.mqtt.python.
- CoAPthon
- Reference: G.Tanganelli, C. Vallati, E.Mingozzi, "CoAPthon: Easy Development of CoAP-based IoT Applications with Python", IEEE World Forum on Internet of Things (WF-IoT 2015)
Additional Library References (for in-class Computer Vision examples):
- imutils
- Reference: A. Rosebrock. imutils. (2020) [Online]. Available: https://pypi.org/project/imutils/.
- opencv-python
- Reference: O. Heinisuo. opencv-python. (2020) [Online]. Available: https://pypi.org/project/opencv-python/.
- opencv-python-headless
- Reference: O. Heinisuo. opencv-python. (2020) [Online]. Available: https://pypi.org/project/opencv-python-headless/.
- opencv-contrib-python
- Reference: O. Heinisuo. opencv-python. (2020) [Online]. Available: https://pypi.org/project/opencv-contrib-python/.
- rtsp
- Reference: M. Stewart. rtsp. (2020) [Online]. Available: https://pypi.org/project/rtsp/.
NOTE: This list will be updated as others are incorporated.
For typical questions (and answers) to the repositories of the Programming the IoT project, please see the FAQ.
This code base is under active development.
If any code samples or other technology this work contains, describes, and / or is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights.
Please see LICENSE if you plan to use this code.
Please refer to the referenced libraries for their respective licenses.