Makahiya – I2C, a burning solution

Hi everybody,

First of all, Happy New Year. I hope that 2017 will be a wonderful year for you (or at least a not too bad one).

Since the beginning of the week, I’ve worked on… I2C ! Following the advices of Samuel and Alexis, I finally added the pull-up resistors and spied the communication with an oscilloscope. But this doesn’t help me to find the problem. And finally, I put the pins on OPENDRAIN mode, and it solved my problem. Such a stupid reason!!! It was due to an assumption I made during my first tests on the I2C: I thought that this parameter (opendrain) only deactivated the internal pull-ups. And in fact, it’s two completely different things… So yesterday evening, I managed to read and write registers of the capacitive sensor.

So this morning, I started to search for the proper values to set and implemented the initialization code. In parallel, I helped Tanguy on the Bluetooth module (because he also had communication problems). My initialization code was not perfect on the first try and I encountered strange behaviors, with the capacitive sensor sometimes suddenly not responding anymore. So I plugged and unplugged it many times. And once, I made a mistake on the connections. As I was solving problems, I didn’t see this one immediately. But after some time, I felt a strange smell, like smoke: the capacitive sensor was very hot. So I unplugged it, made some tests with Perceval’s help, and I’m quite sure that the sensor is dead… Less than 24 hours after the first communication, I lose my sensor… Bad news.

During the end of the week, I will work on the server, and I hope to have a working version before we receive the PCB (probably next Tuesday or Wednesday). For the capacitive sensor, I don’t know if it’s better to wait for the PCBs and continue the tests directly on the PCB or to buy a new evaluation board to finish the tests. This will be discussed tomorrow or Friday.

Makahiya, Week 14.5

Happy new year everyone !


During the holidays, I tried to work on the bluetooth chip but I couldn’t get very far. I continued today and I am now able to communicate between the processor and the bluetooth chip. I will continue and try to establish a communication with another device. I also still have some things to fix regarding the server during the rest of the week.

Makahiya – IFTTT & I2C

Hi everybody,

Just few words to write down what I’ve done since last Sunday. First, I had a look on the ways to interact with our flower. At the beginning, we envisaged to connect it with IFTTT. So I had a deeper look on how to do it and discovered that we have to pay 199$ to do it. For no more than 2 weeks and without any guarantees on the use because it’s possible that we won’t have time to do the connection, I think that for now, we can put this solution aside. So I propose 2 interfaces: a web page and an Android app. These 2 interfaces are quite simple to implement. And if finally, we have time, it won’t be too late to connect our plants with IFTTT.

Then, I worked a little on I2C communication with the capacitive sensors. Some tests allowed me to rule out the device address as the origin of the communication problem. Indeed, the sensor doesn’t respond to any message sent by my own code whereas it properly responds to messages sent by the demo program. And for now, I can’t see any differences… Pull-up resistors also doesn’t seem to be the origin because the bus behaves properly. Obviously, there is at least one difference between the demo board and my own arrangement, still hidden unfortunately. So more work is required.

During the end of the week, I will work a little on the I2C communication.

Next post will be next year, so enjoy the end of 2016 🙂

Makahiya – websockets & I2C

Merry Christmas to everybody,

I hope that each of you can enjoy a wonderful day with his/her family or his/her friends, and that Christmas father has been kind with you.

Just a few words on what I’ve done since last Wednesday. I spent some times working on connecting my Wi-Fi module with the websockets that run on our server. I managed to have first results: connection is established and I can send messages. As I don’t have access to the server and Tanguy doesn’t have Internet access, I can’t have any information on what is received by the server, thus debugging is quite difficult. So next steps will wait a bit.

I also had a look to the I2C driver, in order to talk to the capacitive sensor. I’m able to start a exchange but I don’t receive any ACK from the slave. As I don’t have pull-up resistors, it can be the origin of the problems (the internal pull-ups are said to be too weak). I will add pull-up resistors next week, once returned to Paris, and make new tests with them.

The 2 targets are thus in pause, and I don’t have more to say for now.

My goal hasn’t changed: having both Wi-Fi and capacitive sensors working by the end of the holidays.

Merry Christmas

Makahiya – Wi-Fi and music (again)

Hi everybody,

Yesterday and today, I worked on the Wi-Fi connection and more precisely on downloading a music from the server. As said in my last post, I had some problems of rate. And they are more complex to solve than expected. I was becoming crazy yesterday afternoon, because despite all my efforts and all the improvements I could do, there were still problems. Thus, I decided to make a break and not to touch this part again before at least one week.

But Samuel answered to a question I’d asked on the mailing list, suggesting me to measure the time spent on the blocking functions. As it was quite easy to do, I decided to do it this morning, just to see. And, due to some magical effect, the download of the music worked quite well. So I regained courage and made some cleaning on my code. The sound is not perfect, but now the music is received until the end in most cases, and the error management system doest its work pretty well.

I won’t continue to improve it now as it’s enough for the moment. So this afternoon, I had a look to the websockets implemented by Tanguy on the server, to see how it works. During the second part of this week, I will either work on implementing the connection to the websockets on the board and the reception of commands or start to implement the driver to control the capacitive touch sensors, I don’t know yet. My objective is that these 2 things are finished by the end of the holidays. It’s quite ambitious because I won’t have so many time to work, but that’s my target.

Makahiya, Week 12


Since last time, I continued to work with the server. It was possible to upload a file but apparently not to download it, I had to add a view for this (it looks like static files don’t need a view but non static files do). I also wrote a basic client to communicate with the server. I ended up using the websocket-client library and I was able to listen and write to the server at the same time. But while I was testing this, I saw that the sockets would close with no apparent reason. I tried to solve this problem but I didn’t manage to do it yet. Maybe it is some kind of timeout if the communication stays idle but I’m not sure. But the problem seems to come from the server’s side (so not on the client’s)

During the holidays, I will try to investigate it and I will also begin to work with our Bluetooth module. But I will not always have an internet connection which could be a problem.


Makahiya – Wi-Fi and music

Guten tag von Munich,

On Thursday and Friday, I spent almost all my time working on the Wi-Fi module, trying to understand why I wasn’t able to play music received from the network (and even not able to properly download it completely). On Friday evening, Samuel entirely reviewed the related code with me and helped me correct several mistakes, mainly in the code of the audio part. And it was the right thing to do because now, it works much better: I can receive music (at least the beginning) and play it.

The sound is still not perfect so I have to understand where this problem comes from, but I’m quite confident I will find a way to solve it in the next few days (when I’ll be back to Paris). In fact, I didn’t check the code related to the audio part because I assumed it to be correct as it worked when I transmitted the music on the serial line. But it wasn’t…

So the morality is: if you have something that doesn’t work as it should, review all the code related to it, even the parts that you trust, because you can find there mistakes that previous tests didn’t found.

During the next few days, I’ll try to solve the 2 remaining problems: I can’t download the whole music (downloading abruptly stops at a certain point, that doesn’t seem always the same) and the sound is quite bad (probably due to a lack of data at certain moments, if the download or the exchange between the Wi-Fi module and the micro-processor is too slow).

Makahiya, Week 11.5


During the first part of this week, I continued to work on the server. Now the communication between a client and a plant through two websockets is functional and I can take into account if the plant is connected or not. I also added the possibility to upload an audio file to the server.

The server is also deployed at the same place than Breathup’s and websockets are no longer closed after two minutes of idle time. Thanks to hooks, the server is restarted after each git push with the updated code.

For the rest of the week, I will continue working on the server, maybe I will add authentification or write a client.


Makahiya – Wi-Fi

Hi everybody,

During this first part of the week, I worked on the Wi-Fi module. Unfortunately, I didn’t managed to reach my goal, which was to play music streamed from the server on the development board.
However, I did some things. Command return codes are now properly handled by the program and it’s much easier to communicate with the Wi-Fi module through the development board. For the music, I’m able to receive the data (some data in fact, I have to check if there are differences between data received and the actual content of the audio file). The first problem (which I think will be solved automatically when I would find a solution to make the music player work) is that when I just tried to download the music, I receive a continuous stream of data, without end (at least not in 5 minutes of downloading, for a music that last about 4 minutes…). Second problem is that when I start to decode the input stream (from mp3 to pcm), it stops downloading the rest of the file, whereas these actions are performed in 2 separate threads.

The second part of this week will thus be dedicated (for me) to look for the origin of these problems. And we should also add some automatic tests (at least check that the code compiles) for the Continuous Integration. This will be done after the Wi-Fi/music problem is solved, so probably during the holidays.

Makahiya, Week 11


During the second part of this week, I continued my work with websockets. First, I made them be able to communicate in both ways (in the beginning, I was only sending data, now I can also receive some simultaneously). Then, I tried again to run gunicorn on Heroku. The problem was that gunicorn needs to the port to use in a config file but Heroku allows to use only one specific port that changes every time to deploy. I found a trick that consists in modifying the config file with sed during the deployment. So I was able to deploy our server on Heroku, but we found later that Heroku closes websockets if you don’t use them during 2 minutes, so as we don’t want to ping the server continuously, we will have to deploy our server elsewhere.

Then, I tried to have multiple websockets concurrently. I wanted each socket to have a different URL, the difference being a number at the end of it. With pyramid, it is easy to dispatch URLs with such variables in it and to use the values of these variables for normal views. But aiopyramid that I use to handle websockets like views doesn’t give access to this information. After a long search, I found the problem to be solvable only by adding a line in the code of the library. Later, I also handled the closing of websockets : it crashed on every disconnection, so when we wanted to reopen a websocket at the same URL, it didn’t work. Now, the websockets are properly closed upon disconnection and can be reopened later without any problem.

Next week, I will continue working on the server.