Network Connections - Revision history

Sebastian Kuhlen at 10:30, 2 February 2024

2024-02-02T10:30:54Z

Sebastian Kuhlen at 20:54, 7 July 2022

2022-07-07T20:54:41Z

Sebastian Kuhlen: /* MQTT/CSV */

2022-07-07T20:51:44Z

MQTT/CSV

Sebastian Kuhlen: /* Metadata */

2021-12-08T13:46:46Z

Metadata

Sebastian Kuhlen: /* General implementation and syntax */

2020-12-16T17:04:48Z

General implementation and syntax

Sebastian Kuhlen: /* Examples */

2020-12-11T20:47:11Z

Examples

Sebastian Kuhlen: /* Examples */

2020-12-11T20:45:45Z

Examples

Sebastian Kuhlen: /* MQTT */

2020-12-07T20:46:02Z

MQTT

Sebastian Kuhlen at 20:45, 7 December 2020

2020-12-07T20:45:43Z

Sebastian Kuhlen: /* Network Services (Protocols) */

2020-11-06T16:24:56Z

Network Services (Protocols)

@@ Line 31: / Line 31: @@
      <connection id="..." privacy="..." service="..." address="..." conversion="..." discovery="..." discoveryAddress="..." autoConnect="true/false" interval="...">
          ...
-         <send id="..." type="buffer/meta/time" clear="true/false">...</send>
+         <send id="..." type="buffer/meta/time" keep="true/false">...</send>
          ...
-         <receive id="..." clear="true/false">...</receive>
+         <receive id="..." append="true/false">...</receive>
          ...
      </connection>
@@ Line 62: / Line 62: @@
 The send and receive tags within the connection tag define, which data should be send and received. Each entry has an id with varying meanings. For send tags, the meaning of the id depends on the network service and is usually used as a label that is attached to the data for the remote server. For receive tags, the id is interpreted by the response conversion function and determines which part of the converted response should be used.
-Send tags usually contain a buffer name. Data from this buffer is send using the network service, but it depends on the network service whether only the last value or the entire buffer (array) is submitted. Optionally, a clear attribute can be set to true (default is false). If set to true, the buffer will be cleared after the data has been sent, allowing to easily stream data without duplicates. (The clear attribute here is '''available since phyphox 1.1.11 (file format 1.15)''')
+Send tags usually contain a buffer name. Data from this buffer is sent using the network service, but it depends on the network service whether only the last value or the entire buffer (array) is submitted. Optionally, a keep attribute can be set to false (default is true in contrast to the behavior in analysis modules). If set to false, the buffer will be cleared after the data has been sent, allowing to easily stream data without duplicates. (Note that just like the corresponding attribute in analysis modules, the clear attribute has been deprecated and replaced with keep in phyphox 1.1.13 (file format 1.17)''')
 Alternatively, the attribute "type" can be used to switch from the default type="buffer" to type="meta". In this case, the name in the send tag is not a buffer, but a label that identifies a specific text string of metadata (see list below).
@@ Line 68: / Line 68: @@
 Finally, the type="time" allows for sending the current system time (in seconds since 1970) and possibly time reference events (depending on the data format). This type does not require any content within the tag, so ''<send id="x" type="time" />'' is sufficient. Compact data formats (like GET-parameters of http) will only send the current timestamp, but complex dataformats (like JSON) can also include a list of start/pause events with matching experiment time (seconds since first start of the experiment, skipping pauses) and system time (seconds since 1970) for precise time conversions. ('''Available since phyphox 1.1.8 (file format 1.12)''')
-Receive tags can only have a buffer name inside them and can set the clear attribute. If set to true, the phyphox buffer will be cleared before the received data is written to it. If set to false (default), new data is simply appended.
+Receive tags can only have a buffer name inside them and can set the append attribute. If set to false, the phyphox buffer will be cleared before the received data is written to it. If set to true (default), new data is simply appended. (Note that just like the corresponding attribute in analysis modules, the clear attribute has been deprecated and replaced with append in phyphox 1.1.13 (file format 1.17)''')
 ===Metadata===
@@ Line 211: / Line 211: @@
   <nowiki>
      <connection privacy="..." service="mqtt/csv" address="some.service.com/your/endpoint:1234" receiveTopic="fancySensor/value" conversion="csv" interval="1">
-         <send clear="false" id="phone/pressure" type="buffer" datatype="array">p</send>
+         <send keep="true" id="phone/pressure" type="buffer" datatype="array">p</send>
-         <send clear="false" id="phone/altitude" type="buffer" datatype="number">h</send>
+         <send keep="true" id="phone/altitude" type="buffer" datatype="number">h</send>
-         <receive clear="false">sensordata</receive>
+         <receive append="true">sensordata</receive>
      </connection>
 </nowiki>
@@ Line 235: / Line 235: @@
   <nowiki>
      <connection privacy="..." service="mqtt/json" address="some.service.com/your/endpoint:1234" receiveTopic="fancySensor/value" sendTopic="phone/data" conversion="csv" interval="1">
-         <send clear="false" id="pressure" type="buffer" datatype="array">p</send>
+         <send keep="true" id="pressure" type="buffer" datatype="array">p</send>
-         <send clear="false" id="altitude" type="buffer" datatype="number">h</send>
+         <send keep="true" id="altitude" type="buffer" datatype="number">h</send>
-         <receive clear="false">sensordata</receive>
+         <receive append="true">sensordata</receive>
      </connection>
 </nowiki>

@@ Line 31: / Line 31: @@
      <connection id="..." privacy="..." service="..." address="..." conversion="..." discovery="..." discoveryAddress="..." autoConnect="true/false" interval="...">
          ...
-         <send id="..." type="buffer/meta/time">...</send>
+         <send id="..." type="buffer/meta/time" clear="true/false">...</send>
          ...
          <receive id="..." clear="true/false">...</receive>
@@ Line 62: / Line 62: @@
 The send and receive tags within the connection tag define, which data should be send and received. Each entry has an id with varying meanings. For send tags, the meaning of the id depends on the network service and is usually used as a label that is attached to the data for the remote server. For receive tags, the id is interpreted by the response conversion function and determines which part of the converted response should be used.
-Send tags usually contain a buffer name. Data from this buffer is send using the network service, but it depends on the network service whether only the last value or the entire buffer (array) is submitted. Alternatively, the attribute "type" can be used to switch from the default type="buffer" to type="meta". In this case, the name in the send tag is not a buffer, but a label that identifies a specific text string of metadata (see list below).
+Send tags usually contain a buffer name. Data from this buffer is send using the network service, but it depends on the network service whether only the last value or the entire buffer (array) is submitted. Optionally, a clear attribute can be set to true (default is false). If set to true, the buffer will be cleared after the data has been sent, allowing to easily stream data without duplicates. (The clear attribute here is '''available since phyphox 1.1.11 (file format 1.15)''')
 Finally, the type="time" allows for sending the current system time (in seconds since 1970) and possibly time reference events (depending on the data format). This type does not require any content within the tag, so ''<send id="x" type="time" />'' is sufficient. Compact data formats (like GET-parameters of http) will only send the current timestamp, but complex dataformats (like JSON) can also include a list of start/pause events with matching experiment time (seconds since first start of the experiment, skipping pauses) and system time (seconds since 1970) for precise time conversions. ('''Available since phyphox 1.1.8 (file format 1.12)''')
@@ Line 233: / Line 235: @@
   <nowiki>
      <connection privacy="..." service="mqtt/json" address="some.service.com/your/endpoint:1234" receiveTopic="fancySensor/value" sendTopic="phone/data" conversion="csv" interval="1">
-         <send id="pressure" type="buffer" datatype="array">p</send>
+         <send clear="false" id="pressure" type="buffer" datatype="array">p</send>
-         <send id="altitude" type="buffer" datatype="number">h</send>
+         <send clear="false" id="altitude" type="buffer" datatype="number">h</send>
          <receive clear="false">sensordata</receive>
      </connection>

@@ Line 209: / Line 209: @@
   <nowiki>
      <connection privacy="..." service="mqtt/csv" address="some.service.com/your/endpoint:1234" receiveTopic="fancySensor/value" conversion="csv" interval="1">
-         <send id="phone/pressure" type="buffer" datatype="array">p</send>
+         <send clear="false" id="phone/pressure" type="buffer" datatype="array">p</send>
-         <send id="phone/altitude" type="buffer" datatype="number">h</send>
+         <send clear="false" id="phone/altitude" type="buffer" datatype="number">h</send>
          <receive clear="false">sensordata</receive>
      </connection>
@@ Line 216: / Line 216: @@
 In this setup, phyphox would connect to "some.service.com/your/endpoint:1234" and subscribe to "fancySensor/value". Once every second, it would send all the values from the buffer "p" as a comma separated list to the topic "phone/pressure" and the last value from "h" to the topic "phone/altitude". Every time it does so, it takes the latest message it received under the topic "fancySensor/value" and lets the csv-conversion handle it (typically appending the list of values to sensordata).
 ===MQTT/JSON===

@@ Line 113: / Line 113: @@
 :A version of the sensor
-In this list, [sensor] can be replaces by "accelerometer", "linear_acceleration", "gyroscope", "magnetic_field", "pressure", "temperature", "humidity", "light" and "proximity". Note that in some cases, phyphox will try to find a sensor by its name even though it is not officially designated to be a sensor of that type (for example vendor-specific temperature sensors).
+In this list, [sensor] can be replaced by "accelerometer", "linear_acceleration", "gyroscope", "magnetic_field", "pressure", "temperature", "humidity", "light" and "proximity". Note that in some cases, phyphox will try to find a sensor by its name even though it is not officially designated to be a sensor of that type (for example vendor-specific temperature sensors).
 ==Network Services (Protocols)==

@@ Line 31: / Line 31: @@
      <connection id="..." privacy="..." service="..." address="..." conversion="..." discovery="..." discoveryAddress="..." autoConnect="true/false" interval="...">
          ...
-         <send id="..." type="buffer/meta">...</send>
+         <send id="..." type="buffer/meta/time">...</send>
          ...
          <receive id="..." clear="true/false">...</receive>
@@ Line 63: / Line 63: @@
 Send tags usually contain a buffer name. Data from this buffer is send using the network service, but it depends on the network service whether only the last value or the entire buffer (array) is submitted. Alternatively, the attribute "type" can be used to switch from the default type="buffer" to type="meta". In this case, the name in the send tag is not a buffer, but a label that identifies a specific text string of metadata (see list below).
 Receive tags can only have a buffer name inside them and can set the clear attribute. If set to true, the phyphox buffer will be cleared before the received data is written to it. If set to false (default), new data is simply appended.

← Older revision		Revision as of 20:47, 11 December 2020
Line 281:		Line 281:

	Here are some example XML files for different scenarios, which might help you getting started. Note that most of them will not work out of the box as they require a server to provide or receive data, so you will need to adapt them to your needs.		Here are some example XML files for different scenarios, which might help you getting started. Note that most of them will not work out of the box as they require a server to provide or receive data, so you will need to adapt them to your needs.
		+
		+	'''The network connections are not supported by our web editor. If you want to use this function, you need to download the configuration files and edit them with a text editor.'''

	===HTTP===		===HTTP===

@@ Line 282: / Line 282: @@
 Here are some example XML files for different scenarios, which might help you getting started. Note that most of them will not work out of the box as they require a server to provide or receive data, so you will need to adapt them to your needs.
 ===MQTT===
-[https://phyphox.org/wiki/images/2/23/Mqtt-csv-example.phyphox Send CSV via MQTT]
+====[https://phyphox.org/wiki/images/2/23/Mqtt-csv-example.phyphox Send CSV via MQTT]====
 In this example, time and x acceleration a acquired from the accelerometer (averaging to a rate of 1 Hz) and the last ten readings are sent every 10 seconds as a comma-separated list (CSV) to an MQTT broker at 192.168.2.5. As this example uses comma-separated lists, time and acceleration are sent to separate topics,
-[https://phyphox.org/wiki/images/8/86/Mqtt-json-example.phyphox Send JSON via MQTT]
+====[https://phyphox.org/wiki/images/8/86/Mqtt-json-example.phyphox Send JSON via MQTT]====
 This example only sends data when a button is pressed. It then takes the latest readings from the accelerometer and send x, y and z component as a JSON object to the topic "phyphox/acc" on an MQTT broker at 192.168.2.5.
-[https://phyphox.org/wiki/images/1/1d/Octoprint.phyphox Octoprint tool temperature]
+====[https://phyphox.org/wiki/images/1/1d/Octoprint.phyphox Octoprint tool temperature]====
 This example connects to an MQTT broker at 192.168.2.5 and subscribes to the topic octoPrint/temperature/tool0 which is used by the 3d printing software "octoprint" to report the current tool temperature. The phyphox experiment adds a timestamp and plots the current temperature and the target temperature over time. Note, that Octoprint sends JSON messages, but as this example should not write anything to the topic, it uses "mqtt/csv" as a service and "json" as a conversion function to decode the json data.
-[https://phyphox.org/wiki/images/0/0f/Octoprint2.phyphox Octoprint tool and bed temperature]
+====[https://phyphox.org/wiki/images/0/0f/Octoprint2.phyphox Octoprint tool and bed temperature]====
 Like the simpler Octoprint example above, but this example subscribes to two topics to print the bed temperature as well. Note that adding a timestamp to both temperatures is what makes this example so rather large.

← Older revision		Revision as of 20:45, 7 December 2020
Line 277:		Line 277:

	Discovery methods like mDNS are not yet implemented, but will follow soon. For now, you can only work with fixed targets.		Discovery methods like mDNS are not yet implemented, but will follow soon. For now, you can only work with fixed targets.
		+
		+	==Examples==
		+
		+	Here are some example XML files for different scenarios, which might help you getting started. Note that most of them will not work out of the box as they require a server to provide or receive data, so you will need to adapt them to your needs.
		+
		+
		+	===MQTT===
		+
		+	[https://phyphox.org/wiki/images/2/23/Mqtt-csv-example.phyphox Send CSV via MQTT]
		+	In this example, time and x acceleration a acquired from the accelerometer (averaging to a rate of 1 Hz) and the last ten readings are sent every 10 seconds as a comma-separated list (CSV) to an MQTT broker at 192.168.2.5. As this example uses comma-separated lists, time and acceleration are sent to separate topics,
		+
		+	[https://phyphox.org/wiki/images/8/86/Mqtt-json-example.phyphox Send JSON via MQTT]
		+	This example only sends data when a button is pressed. It then takes the latest readings from the accelerometer and send x, y and z component as a JSON object to the topic "phyphox/acc" on an MQTT broker at 192.168.2.5.
		+
		+	[https://phyphox.org/wiki/images/1/1d/Octoprint.phyphox Octoprint tool temperature]
		+	This example connects to an MQTT broker at 192.168.2.5 and subscribes to the topic octoPrint/temperature/tool0 which is used by the 3d printing software "octoprint" to report the current tool temperature. The phyphox experiment adds a timestamp and plots the current temperature and the target temperature over time. Note, that Octoprint sends JSON messages, but as this example should not write anything to the topic, it uses "mqtt/csv" as a service and "json" as a conversion function to decode the json data.
		+
		+	[https://phyphox.org/wiki/images/0/0f/Octoprint2.phyphox tool and bed temperature]
		+	Like the simpler Octoprint example above, but this example subscribes to two topics to print the bed temperature as well. Note that adding a timestamp to both temperatures is what makes this example so rather large.

@@ Line 183: / Line 183: @@
 The MQTT/CSV service connects to an MQTT broker at the given address and will send the data of "send" blocks there. Each entry of "send" will generate an individual message, using the ID as the MQTT topic. You may set a datatype for each send with "array" (default) sending a comma-separated list of all values in the buffer and "number" only sending the last value.
-If a `receiveTopic` is set, it will subscribe to this topic (or set of topics if MQTT-typical wildcards are used) and will treat the payload of the last received message as response (not that there is no mechanism to assign responses to requests - it is very likely that this received message was received before a message was sent).
+If a `receiveTopic` is set, it will subscribe to this topic (or set of topics if MQTT-typical wildcards are used) and will treat the payload of each received message as response (note that there is no mechanism to assign responses to requests - it is very likely that this received message was received before a message was sent).
 Example:
@@ Line 208: / Line 208: @@
 The MQTT/JSON service connects to an MQTT broker at the given address and will send the data of "send" blocks there. All entries of "send" will be combined into a single JSON object using their resective ID (also see "HTTP/POST"). The JSON string will be send to the MQTT topic set as sendTopic. You may set a datatype for each send with "array" (default) sending a JSON Array of all values in the buffer and "number" only sending the last value as individual number.
-If a `receiveTopic` is set, it will subscribe to this topic (or set of topics if MQTT-typical wildcards are used) and will treat the payload of the last received message as response (not that there is no mechanism to assign responses to requests - it is very likely that this received message was received before a message was sent).
+If a `receiveTopic` is set, it will subscribe to this topic (or set of topics if MQTT-typical wildcards are used) and will treat the payload of the all received message as response (note that there is no mechanism to assign responses to requests - it is very likely that this received message was received before a message was sent).
 Example: