05-03-2020, 08:53 PM
There seems to be quite a list of things I have to comment on here. I hope I found them all, but if I missed something, we will probably get there eventually.
Unfortunately, we do not want to share our exact php file publicly. The problem here is that we have an interface that is meant to allow many participants to submit pretty much any data with limited possibilities to reject nonsense (i.e. intentionally wrong) data. This is mostly done with some sanity checks for the data, which works better if the details are not known. Also, there are some additional security and privacy concerns that should be obvious by someone running a publicly available server, which we do not want to detail in an exact guide on how to set up a server. For example, our script simply dumps the data into a file on the server, which (quite obviously) should not be publicly readable, especially if location data is collected. If we simply post our php, which dumps the data into a subdirectory, it is very tempting to just use it without setting up an appropriate htaccess file.
We have just done this experiment ourselves and we are currently working on a publication for this, so at the moment, there is only the documentation for the phyphox part aimed at users who set up their own server.
I do not see an actual problem here, but I am wondering where this comes from. The attribute "mode" was part of an earlier draft to determine whether the submission should be done with a button (trigger) or periodically. We eventuelly dropped this attribute as it was not necessary. If you set interval (as you do), it will send the data periodically and if you attach a button, you can trigger it with the button - or both. I am just wondering where I forgot to remove the old attribute.
BTW: interval=10 sends the data every 10 seconds - regardless of the averaging of the sensor.
Is this error displayed in phyphox or did you get this error in your server's log file? In phyphox I would expect a message like "Could not parse JSON" as phyphox tries to interpret the response from the server as incoming data, which is set to JSON (the so far only available format). It sounds like you are calling the file from a web browser to see this error, which does not make much sense. This is not how PHP works. The $_GET is only set when you call the URL with parameters, so unless you append the parameters in your browser, you can expect that. In phyphox you will not see the page itself, but phyphox will try to parse the answer (you can for example answer with {"result": 1} to give feedback to the user that the submission has been accepted and use this in phyphox to display information). What you need to do (unless you in fact observe the results in the server logs) is to store the submitted data somewhere to inspect it later. For testing, a simple "file_put_contents" should be sufficient.
Also, you set service to "http/post", so phyphox will not encode the data in the URL but will submit it via post. However, you cannot simply access $_POST, because phyphox uses JSON as POST format, which is not the default format for PHP. You need to read the data from the input and decode the JSON first. See the two PHP lines at https://phyphox.org/wiki/index.php/Netwo...TTP.2FPOST.
The JSON part tells phyphox how to interpret the response - not how to encode the data it is sending (see https://phyphox.org/wiki/index.php/Netwo...tions#JSON). Since you are not trying to interpret the response and since phyphox so far only has this one option, this does not make a difference. Again, it is not clear to me how you obtain the answer. Phyphox does not show it to you and calling the page from a browser does not make any sense unless you try to test your PHP file. PHP does not have share variables across multiple calls to the page (unless we talk about some advanced stuff) and you need to store your data somewhere. (Sorry, I hope that I did not totally misinterpret what you did there...)
Good idea. Not entirely sure what went wrong though. Could you upload the file you sent? The error suggests that already the second character is unexpected. The error comes from Android's XML parser even before phyphox tries to understand it...
Never seen this one before. From which app did you try to open the phyphox file? The error says that the app from which you launch the phyphox file indeed opened phyphox (obviously) but phyphox does not have permission to read the file. My guess is that either this is on an external storage and you did not give phyphox the permission to read from the external storage or that this is a bug in the other app, as the permission has to be granted by the calling app. Again, if you tell me which it is, I would like to try it.
Simple suggestion for testing:
As you are already running a web server, place your phyphox file on the webserver and generate a QR code pointing to it. We introduced the QR code because calling phyphox-files from other apps is quite messy because they are not a common format.
Hope all this helps to get a few steps further. You are trying a new function that we barely documented so far and which probably will always be targeted at advanced users, but it is very interesting for us to see which difficulties you encounter, so at least we can smooth out some parts of the process of setting this up.
(05-02-2020, 02:25 PM)julien Wrote: Could it be possible for you to share the .php file you ran on your server for this live experiment ?
Unfortunately, we do not want to share our exact php file publicly. The problem here is that we have an interface that is meant to allow many participants to submit pretty much any data with limited possibilities to reject nonsense (i.e. intentionally wrong) data. This is mostly done with some sanity checks for the data, which works better if the details are not known. Also, there are some additional security and privacy concerns that should be obvious by someone running a publicly available server, which we do not want to detail in an exact guide on how to set up a server. For example, our script simply dumps the data into a file on the server, which (quite obviously) should not be publicly readable, especially if location data is collected. If we simply post our php, which dumps the data into a subdirectory, it is very tempting to just use it without setting up an appropriate htaccess file.
We have just done this experiment ourselves and we are currently working on a publication for this, so at the moment, there is only the documentation for the phyphox part aimed at users who set up their own server.
(05-02-2020, 02:25 PM)julien Wrote: <network>
<connection address="https://192.168.1.41:6023/blog/live.php" autoConnect="true" service="http/post" mode="trigger" id="submit" conversion="json" interval="10">
<send id="abs" type="buffer">abs</send> </connection>
</network>
I do not see an actual problem here, but I am wondering where this comes from. The attribute "mode" was part of an earlier draft to determine whether the submission should be done with a button (trigger) or periodically. We eventuelly dropped this attribute as it was not necessary. If you set interval (as you do), it will send the data periodically and if you attach a button, you can trigger it with the button - or both. I am just wondering where I forgot to remove the old attribute.
BTW: interval=10 sends the data every 10 seconds - regardless of the averaging of the sensor.
(05-02-2020, 02:25 PM)julien Wrote: <?php
echo $_GET["abs"]
?>
And i get this error :
Notice: Undefined index: abs in C:\ENTBOX\htdocs\blog\live.php on line 2
Is this error displayed in phyphox or did you get this error in your server's log file? In phyphox I would expect a message like "Could not parse JSON" as phyphox tries to interpret the response from the server as incoming data, which is set to JSON (the so far only available format). It sounds like you are calling the file from a web browser to see this error, which does not make much sense. This is not how PHP works. The $_GET is only set when you call the URL with parameters, so unless you append the parameters in your browser, you can expect that. In phyphox you will not see the page itself, but phyphox will try to parse the answer (you can for example answer with {"result": 1} to give feedback to the user that the submission has been accepted and use this in phyphox to display information). What you need to do (unless you in fact observe the results in the server logs) is to store the submitted data somewhere to inspect it later. For testing, a simple "file_put_contents" should be sufficient.
Also, you set service to "http/post", so phyphox will not encode the data in the URL but will submit it via post. However, you cannot simply access $_POST, because phyphox uses JSON as POST format, which is not the default format for PHP. You need to read the data from the input and decode the JSON first. See the two PHP lines at https://phyphox.org/wiki/index.php/Netwo...TTP.2FPOST.
(05-03-2020, 04:27 PM)julien Wrote: I have removed the json part of the phyphox program. The network part now is :
<network>
<connection address="https://192.168.1.5:6023/blog/live.php" autoConnect="true" service="http/get" mode="trigger" id="submit" interval="10">
<send id="abs" type="buffer">abs</send> </connection>
</network>
the php file is :
<?php
var_dump($GLOBALS)
?>
And i have this page:
array(5) { ["_GET"]=> array(0) { } ["_POST"]=> array(0) { } ["_COOKIE"]=> array(0) { } ["_FILES"]=> array(0) { } ["GLOBALS"]=> *RECURSION* }
It seems there is no data at all...
The JSON part tells phyphox how to interpret the response - not how to encode the data it is sending (see https://phyphox.org/wiki/index.php/Netwo...tions#JSON). Since you are not trying to interpret the response and since phyphox so far only has this one option, this does not make a difference. Again, it is not clear to me how you obtain the answer. Phyphox does not show it to you and calling the page from a browser does not make any sense unless you try to test your PHP file. PHP does not have share variables across multiple calls to the page (unless we talk about some advanced stuff) and you need to store your data somewhere. (Sorry, I hope that I did not totally misinterpret what you did there...)
(05-03-2020, 04:27 PM)julien Wrote: But I think I have found where my problem comes from :Correct. The editor does not yet know about the network interface and it does not just create a QR code but parses and recreated the experiment (this reduces the risk of our service being abused as a general hosting service).
Until now I wrote the program in notepad++, then I uploaded it in the phyphox editor in order to create a qr code to upload the program in my phone. But may be the editor doesn’t take the network part into account.
(05-03-2020, 04:27 PM)julien Wrote: So I tried to send the .phyphox file by email to my phone. When I open it from the email I have this error :
Good idea. Not entirely sure what went wrong though. Could you upload the file you sent? The error suggests that already the second character is unexpected. The error comes from Android's XML parser even before phyphox tries to understand it...
(05-03-2020, 04:27 PM)julien Wrote: And when I upload it first in my phone and then open it I have this error :
Never seen this one before. From which app did you try to open the phyphox file? The error says that the app from which you launch the phyphox file indeed opened phyphox (obviously) but phyphox does not have permission to read the file. My guess is that either this is on an external storage and you did not give phyphox the permission to read from the external storage or that this is a bug in the other app, as the permission has to be granted by the calling app. Again, if you tell me which it is, I would like to try it.
Simple suggestion for testing:
As you are already running a web server, place your phyphox file on the webserver and generate a QR code pointing to it. We introduced the QR code because calling phyphox-files from other apps is quite messy because they are not a common format.
Hope all this helps to get a few steps further. You are trying a new function that we barely documented so far and which probably will always be targeted at advanced users, but it is very interesting for us to see which difficulties you encounter, so at least we can smooth out some parts of the process of setting this up.