Starting to think it might be an aws iot code issue. This is trying to set up a new device, and using their setup script. It at least starts to work, because on the aws monitor dashboard I see connections. This is the output it gives. I am posting this on their sdk issues too https://github.com/aws/aws-iot-device-sdk-python/issues/85
Running pub/sub sample application...
2017-11-01 05:13:53,808 - AWSIoTPythonSDK.core.protocol.internal.clients - DEBUG - Initializing MQTT layer...
2017-11-01 05:13:53,817 - AWSIoTPythonSDK.core.protocol.internal.clients - DEBUG - Registering internal event callbacks to MQTT layer...
2017-11-01 05:13:53,822 - AWSIoTPythonSDK.core.protocol.internal.workers - DEBUG - Event consuming thread started
2017-11-01 05:13:53,825 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - MqttCore initialized
2017-11-01 05:13:53,828 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Client id: basicPubSub
2017-11-01 05:13:53,832 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Protocol version: MQTTv3.1.1
2017-11-01 05:13:53,834 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Authentication type: TLSv1.2 certificate based Mutual Auth.
2017-11-01 05:13:53,838 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Configuring endpoint...
2017-11-01 05:13:53,842 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Configuring certificates...
2017-11-01 05:13:53,845 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Configuring reconnect back off timing...
2017-11-01 05:13:53,848 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Base quiet time: 1.000000 sec
2017-11-01 05:13:53,852 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Max quiet time: 32.000000 sec
2017-11-01 05:13:53,855 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Stable connection time: 20.000000 sec
2017-11-01 05:13:53,859 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Configuring offline requests queueing: max queue size: -1
2017-11-01 05:13:53,864 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Configuring offline requests queue draining interval: 0.500000 sec
2017-11-01 05:13:53,869 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Configuring connect/disconnect time out: 10.000000 sec
2017-11-01 05:13:53,873 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Configuring MQTT operation time out: 5.000000 sec
2017-11-01 05:13:53,876 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Performing sync connect...
2017-11-01 05:13:53,879 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Performing async connect...
2017-11-01 05:13:53,883 - AWSIoTPythonSDK.core.protocol.mqtt_core - INFO - Keep-alive: 30.000000 sec
2017-11-01 05:13:53,886 - AWSIoTPythonSDK.core.protocol.mqtt_core - DEBUG - Passing in general notification callbacks to internal client...
2017-11-01 05:13:53,890 - AWSIoTPythonSDK.core.protocol.internal.clients - DEBUG - Filling in fixed event callbacks: CONNACK, DISCONNECT, MESSAGE
Traceback (most recent call last):
File "aws-iot-device-sdk-python/samples/basicPubSub/basicPubSub.py", line 89, in <module>
File "/usr/lib/python2.7/site-packages/AWSIoTPythonSDK/MQTTLib.py", line 408, in connect
File "/usr/lib/python2.7/site-packages/AWSIoTPythonSDK/core/protocol/mqtt_core.py", line 168, in connect
File "/usr/lib/python2.7/site-packages/AWSIoTPythonSDK/core/protocol/mqtt_core.py", line 179, in connect_async
rc = self._internal_async_client.connect(keep_alive_sec, ack_callback)
File "/usr/lib/python2.7/site-packages/AWSIoTPythonSDK/core/protocol/internal/clients.py", line 113, in connect
rc = self._paho_client.connect(host, port, keep_alive_sec)
File "/usr/lib/python2.7/site-packages/AWSIoTPythonSDK/core/protocol/paho/client.py", line 654, in connect
File "/usr/lib/python2.7/site-packages/AWSIoTPythonSDK/core/protocol/paho/client.py", line 797, in reconnect
File "/usr/lib/python2.7/ssl.py", line 943, in wrap_socket
File "/usr/lib/python2.7/ssl.py", line 552, in init
ssl.SSLError: unknown error (_ssl.c:2947)
Exception in thread Thread-1 (most likely raised during interpreter shutdown):
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner
File "/usr/lib/python2.7/threading.py", line 754, in run
File "/usr/lib/python2.7/site-packages/AWSIoTPythonSDK/core/protocol/internal/workers.py", line 137, in _dispatch
File "/usr/lib/python2.7/threading.py", line 289, in exit
File "/usr/lib/python2.7/threading.py", line 216, in exit
File "/usr/lib/python2.7/threading.py", line 203, in release
<type 'exceptions.TypeError'>: 'NoneType' object is not callable
I did a factory reset to the Omega.
I went back to the documentation and followed all the steps from the beginning.
I came to the blink program called 'STK01-blink'.
I saved 'STK01-blink' to my Omega. I went to the terminal ran the code and IT WORKS!!!!
So, after playing with the onionGpio module a bit more, I've reluctantly concluded that I can't use it to read gpio input that's reliable enough to do things like read a rotary encoder, even after fixing the bug in what it returns for getValue(). The trouble is partly that reading a pin is really slow because the implementation uses file manipulation and file I/O to read the bit in a hardware register somewhere that represents the pin. And partly it's because Python, being a garbage-collecting language, might take a break from executing your code to do a bunch of housekeeping between one of line of your code and the next. (Maybe it's possible to tell the Python environment to hold off on housekeeping stuff for a section of code. Some languages that garbage collect let you do that. I wouldn't know. But doing a getValue() executes a lot of code, as I said.)
That means, for example, that if you're trying to decide which pin went HIGH first, pin1 or pin2, you can't do it reliably at the millisecond level by doing
@Joris-Mulliez I agree that PHP is of no use here, however I have plans to take this further, and wanted to start with the PHP base to work into. I am taking small steps into this whole new computing world for me. Yes, I could have just had the Python write out to "index.htm" and left it there, however what I am now doing is even beyond that. I want the initial page to allow for the selection of ZIP, City, PWS, Lat/Long and to set the refresh rate. This is only a backbone to grow from.
I know this is an old thread but I just got HomeAssistant running on my Omega2+ and wanted to follow up. I did the following;
I factory reset my Omega2+ to latest software/console
I extended the storage to use the SD card (3GB)
I added a 250MB swap file to extend the memory
I installed python 3, pip3 and upgraded pip3 setuptools
I also didn't use virtualenv. HomeAssistant installed and ran without any special changes and I could view the UI at http://omega-xxxx.local:8123/. It did take a very long time (20 mins) to install and run though.
Like Vinicius said, if you have no real reason to use something like C and can get away with python, if it is not crucial to have a fast initialization time, I would go with Python. Also, the difference between python 2 and 3 is minimal. Really 3 is just making things a little more consistent. Mostly if you change your print "ok" to print("ok") that should do it. I would go with python 2.
One suggestion. I have found that it is faster to use os.system() for some things rather than their python equivalents. Perhaps you could look into that?
@Alan-Smith Right now we are still writing a wrapper for the OLED library. However, we do have an older version of a python library for the OLED here: https://github.com/OnionIoT/Python-OLED. However, this library uses smbus, which we haven't had a chance to compile for the Omega yet. If you are feeling adventures you can try to compile it.
@Rudy-Trujillo We are still working on python wrappers for our libraries. So at this point it might be easier for you to use the Linux command line to control the pins. You can try the fast-gpio utility.
Looks like your connection to Onion Community was lost, please wait while we try to reconnect.