IoT Management - Revision history

Ctreber at 17:05, 15 June 2018

2018-06-15T17:05:46Z

← Older revision		Revision as of 17:05, 15 June 2018
Line 3:		Line 3:
	=IoT Management - How to Manage an Installation=		=IoT Management - How to Manage an Installation=

	Something that I noticed (even) at home: Once you deployed a number of IoT devices, some ~~questions arise~~:		Something that I noticed (even) at home: Once you deployed a number of IoT devices, you'll notice some things need addressing that haven't crossed your mind before:

	* ~~Does~~ a device ~~have~~ a problem?		* How do I know a device has a problem?
	* What devices are actually deployed? Where?		* What devices are actually deployed? Where?
	* What software versions are in use (~~devices,~~ IoT framework, capabilities)?		* What software versions are in use (IoT framework, devices, capabilities)?
	* What topics are in use? Who is publishing, who is subscribing? What is being published? ~~How often~~?		* What topics are in use? Who is publishing, who is subscribing? What topics are being published and subscribed to? What are the latest messages?
	* ~~Security - currently~~ I rely on the privacy of my WLAN, but I guess message exchange via SSL would be "really nice" (and require a reworking of my infrastructure)		* How do I secure the whole thing? Currently I rely on the privacy of my WLAN, but I guess message exchange via SSL would be "really nice" (and require a reworking of my infrastructure)

	~~Ingredients~~ to the solution ~~are~~		I came up with the following ingredients to the solution

	* [[Tools]] to monitor what is going on in the network		* [[Tools]] to monitor what is going on in the network
Line 32:		Line 32:
	My devices report the software version of		My devices report the software version of

			* the IoT framework
	* the device (like, "gardener")		* the device (like, "gardener")
	* each capability (like, "watering", "temperature")		* each capability (like, "watering", "temperature")
	* the underlying IoT framework

	This allows me to find devices which need to be, or could be updated.		This allows me to find devices which need to be, or could be updated.

	REM The Arduino/ ESP8266 combination I use does NOT allow for over the air updates. But, all devices have a plug that allows for in-place SPI programming. REM On a second thought - the Arduino could download the update to the ESP, and then the ESP flashes the Arduino ~~- hmmm~~...		REM The Arduino/ ESP8266 combination I use does NOT allow for over the air updates. But, all devices have a plug that allows for in-place SPI programming. REM On a second thought - the Arduino could download the update to the ESP, and then the ESP flashes the Arduino. Or two Arduinos (€2.50 from China) flash each other. Hmmm...

	==Location==		==Location==

	With enough devices deployed, the MQTT-ID may or may not tell you enough to find out where the device is physically located (maybe it even moves?).		With enough devices deployed, the MQTT-ID may or may not tell you enough to find out where the device is physically located (maybe it even moves?). It would be nice to save the location as part of the configuration, and have the device report on it on request or when rebooting.

	[[IoT with AME\|Home]]		[[IoT with AME\|Home]]

	__NOTOC__		__NOTOC__

Ctreber at 13:00, 15 June 2018

2018-06-15T13:00:09Z

← Older revision		Revision as of 13:00, 15 June 2018
Line 1:		Line 1:
	[[IoT with AME\|Home]]		[[IoT with AME\|Home]]

	=Management - How to ~~manage~~ an ~~IoT installation~~=		=IoT Management - How to Manage an Installation=

	Something that I noticed (even) at home: Once you deployed a number of IoT devices, some questions arise:		Something that I noticed (even) at home: Once you deployed a number of IoT devices, some questions arise:

	* Does a device have a problem?		* Does a device have a problem?
	* What devices are actually deployed?		* What devices are actually deployed? Where?
	* What software versions are in use (devices, IoT framework, capabilities)?		* What software versions are in use (devices, IoT framework, capabilities)?
	* What topics are in use? Who is publishing, who is subscribing? What is being published? How often?		* What topics are in use? Who is publishing, who is subscribing? What is being published? How often?

Ctreber: Ctreber moved page Management to IoT Management without leaving a redirect

2018-06-15T12:59:10Z

Ctreber moved page Management to IoT Management without leaving a redirect

← Older revision	Revision as of 12:59, 15 June 2018
(No difference)

Ctreber at 22:44, 14 June 2018

2018-06-14T22:44:41Z

← Older revision		Revision as of 22:44, 14 June 2018
Line 15:		Line 15:
	* [[Tools]] to monitor what is going on in the network		* [[Tools]] to monitor what is going on in the network
	* [[Naming and Behavioral Conventions]] that allow for systematic collection and analysis of data, and for controlling devices		* [[Naming and Behavioral Conventions]] that allow for systematic collection and analysis of data, and for controlling devices


	==Operational Status==		==Operational Status==
Line 22:		Line 21:

	Sometime devices even don't connect or experience other hangups. My devices use a self-developed logging facility called "Logsury" that, among others things, is able to output logging information via I2C. When I connect my programmer to a device I get logging output displayed on a LCD (note to self: extend to main connector to include A4 and A5; there are enough free pins to use). Of course, any other device capable of receiving I2C transmissions can display that information.		Sometime devices even don't connect or experience other hangups. My devices use a self-developed logging facility called "Logsury" that, among others things, is able to output logging information via I2C. When I connect my programmer to a device I get logging output displayed on a LCD (note to self: extend to main connector to include A4 and A5; there are enough free pins to use). Of course, any other device capable of receiving I2C transmissions can display that information.


	==Network==		==Network==
Line 29:		Line 27:

	Additionally, I use a programmable RGB LED to display the (predominantly network) status of the device in a directly observable fashion. I get information about connecting to the WLAN, connecting to the MQTT broker, pings sent and received, and publications send and received. This actually has often helped me to pin-point troubles.		Additionally, I use a programmable RGB LED to display the (predominantly network) status of the device in a directly observable fashion. I get information about connecting to the WLAN, connecting to the MQTT broker, pings sent and received, and publications send and received. This actually has often helped me to pin-point troubles.


	==Software==		==Software==
Line 42:		Line 39:

	REM The Arduino/ ESP8266 combination I use does NOT allow for over the air updates. But, all devices have a plug that allows for in-place SPI programming. REM On a second thought - the Arduino could download the update to the ESP, and then the ESP flashes the Arduino - hmmm...		REM The Arduino/ ESP8266 combination I use does NOT allow for over the air updates. But, all devices have a plug that allows for in-place SPI programming. REM On a second thought - the Arduino could download the update to the ESP, and then the ESP flashes the Arduino - hmmm...


	==Location==		==Location==
Line 49:		Line 45:

	[[IoT with AME\|Home]]		[[IoT with AME\|Home]]

			__NOTOC__

Ctreber at 15:28, 17 July 2017

2017-07-17T15:28:32Z

← Older revision		Revision as of 15:28, 17 July 2017
Line 17:		Line 17:


	==Status==		==Operational Status==

	All ~~may~~ devices are reporting their status under topic "<mqttID>/status". Subscribing to "+/status" gives me an overview about what devices are deployed, and how they are doing connection-wise.		All my devices are reporting their status under topic "<mqttID>/status". Subscribing to "+/status" gives me an overview about what devices are deployed, and how they are doing connection-wise.

	~~Additionally~~, I ~~use~~ a ~~programmable RGB LED to display the status of the~~ device ~~in a directly observable fashion.~~ I get ~~information about connecting~~ to ~~the WLAN, connecting~~ to ~~the MQTT broker, pings sent~~ and ~~received~~, ~~and publications send and received. This actually has often helped a lot to pin-point troubles~~.		Sometime devices even don't connect or experience other hangups. My devices use a self-developed logging facility called "Logsury" that, among others things, is able to output logging information via I2C. When I connect my programmer to a device I get logging output displayed on a LCD (note to self: extend to main connector to include A4 and A5; there are enough free pins to use). Of course, any other device capable of receiving I2C transmissions can display that information.

	My devices use a self-developed logging facility called "Logsury" that, among others things, is able to output logging information via I2C. When I connect my programmer to a device I get logging output displayed on a LCD (note to self: extend to main connector to include A4 and A5; there are enough free pins to use).

			==Network==

	~~==Network==~~		Similarly, my devices report their IP and MAC addresses. Once devices are able to connect to more than one WLAN, they should report the SSID in use as well. This helps setting up routers, firewalls, and the like.

	~~Similarly~~, ~~they report their IP and MAC addresses~~. ~~Once devices are able~~ to ~~connect to more than one~~ WLAN, ~~they should report~~ the ~~SSID in use as well~~.		Additionally, I use a programmable RGB LED to display the (predominantly network) status of the device in a directly observable fashion. I get information about connecting to the WLAN, connecting to the MQTT broker, pings sent and received, and publications send and received. This actually has often helped me to pin-point troubles.


	==Software==		==Software==

	My devices report the software version of the device, of each capability, ~~and~~ the underlying IoT framework. This allows me to find devices which need to be or could be updated.		My devices report the software version of

			* the device (like, "gardener")
			* each capability (like, "watering", "temperature")
			* the underlying IoT framework

			This allows me to find devices which need to be, or could be updated.

	REM The Arduino/ ESP8266 combination I use does NOT allow for over the air updates ~~(on~~ a second thought - the Arduino could download the update to the ESP, and then ~~I use~~ the ESP ~~to flash~~ the Arduino). ~~All my devices have a plug that allows for in-place SPI programming~~.		REM The Arduino/ ESP8266 combination I use does NOT allow for over the air updates. But, all devices have a plug that allows for in-place SPI programming. REM On a second thought - the Arduino could download the update to the ESP, and then the ESP flashes the Arduino - hmmm...


	==Location==		==Location==

	With enough devices, the MQTT-ID may or may not tell you enough to find out where the device is physically located (maybe it even moves?).		With enough devices deployed, the MQTT-ID may or may not tell you enough to find out where the device is physically located (maybe it even moves?).

	[[IoT with AME\|Home]]		[[IoT with AME\|Home]]

Ctreber at 15:01, 17 July 2017

2017-07-17T15:01:57Z

← Older revision		Revision as of 15:01, 17 July 2017
Line 20:		Line 20:

	All may devices are reporting their status under topic "<mqttID>/status". Subscribing to "+/status" gives me an overview about what devices are deployed, and how they are doing connection-wise.		All may devices are reporting their status under topic "<mqttID>/status". Subscribing to "+/status" gives me an overview about what devices are deployed, and how they are doing connection-wise.

			Additionally, I use a programmable RGB LED to display the status of the device in a directly observable fashion. I get information about connecting to the WLAN, connecting to the MQTT broker, pings sent and received, and publications send and received. This actually has often helped a lot to pin-point troubles.

			My devices use a self-developed logging facility called "Logsury" that, among others things, is able to output logging information via I2C. When I connect my programmer to a device I get logging output displayed on a LCD (note to self: extend to main connector to include A4 and A5; there are enough free pins to use).


Line 29:		Line 33:
	==Software==		==Software==

	My devices report the software version of the device, of each capability, and the underlying IoT framework. This allows me to find devices which need to be or could be updated.		My devices report the software version of the device, of each capability, and the underlying IoT framework. This allows me to find devices which need to be or could be updated.

			REM The Arduino/ ESP8266 combination I use does NOT allow for over the air updates (on a second thought - the Arduino could download the update to the ESP, and then I use the ESP to flash the Arduino). All my devices have a plug that allows for in-place SPI programming.

Ctreber: Created page with "Home =Management - How to manage an IoT installation= Something that I noticed (even) at home: Once you deployed a number of IoT devices, some questions ari..."

2017-07-17T11:13:45Z

Created page with "Home =Management - How to manage an IoT installation= Something that I noticed (even) at home: Once you deployed a number of IoT devices, some questions ari..."

New page

[[IoT with AME|Home]]

=Management - How to manage an IoT installation=

Something that I noticed (even) at home: Once you deployed a number of IoT devices, some questions arise:

* Does a device have a problem?
* What devices are actually deployed?
* What software versions are in use (devices, IoT framework, capabilities)?
* What topics are in use? Who is publishing, who is subscribing? What is being published? How often?
* Security - currently I rely on the privacy of my WLAN, but I guess message exchange via SSL would be "really nice" (and require a reworking of my infrastructure)

Ingredients to the solution are

* [[Tools]] to monitor what is going on in the network
* [[Naming and Behavioral Conventions]] that allow for systematic collection and analysis of data, and for controlling devices

==Status==

All may devices are reporting their status under topic "<mqttID>/status". Subscribing to "+/status" gives me an overview about what devices are deployed, and how they are doing connection-wise.

==Network==

Similarly, they report their IP and MAC addresses. Once devices are able to connect to more than one WLAN, they should report the SSID in use as well.

==Software==

My devices report the software version of the device, of each capability, and the underlying IoT framework. This allows me to find devices which need to be or could be updated.

==Location==

With enough devices, the MQTT-ID may or may not tell you enough to find out where the device is physically located (maybe it even moves?).

[[IoT with AME|Home]]