COM'CENDRIER

• Selim HAMADOUCHE
• Galin LIPCHEV
• Nicolas NOUIRA

Julien, student in IT and smoker since many years, would like to reduce his cigarette consumption because it is very expensive to smoke. Indeed, the average cigarette pack price reaches 7€. Unfortunately, he is dependent on the cigarette and doesn't imagine himself stop smoking.
One night, while surfing on the web, he noticed an advertisement for a communicating ashtray : The COM'CENDRIER. Intrigued, he took an interest in these ashtray features and decided to buy it.
After receiving the ashtray, he put it on the edge of his window because this is the place where he usually smoke. He configured the ashtray via the web interface and started to smoke. As he was impatient, he took a look at the high added value service, but he didn't see anything since the ashtray didn't save any data.
A week later, he looked the service again and saw some data were saved. So he decided to take this week as a reference and to reduce his cigarette consumption.
The following week, when he consulted his monitoring, he realized his consumption had decreased of 5%. He was proud of himself and continued his effort.
Some days later, he consulted his consumption again and realized it increased of 2%. So he requested the service to display the ashtray data according to the TV program.
He realized he had smoked the most during the soccer match he watched on Tuesday.Indeed he remembered he usually smoked more while watching soccer. So he decided to pay more attention to his consumption and to do more efforts.

• Dimitry ZEKROUF

Folder

Picture

Picture1 Picture2

Picture

Youtube Video

• Force sensor FSR03
  • Resseller
  • Datasheet

• Gas sensor MQ9
  • Resseller
  • Datasheet

Output interface

• Cigarette lit event (start date)
• Cigarette out event (end date)
• Cigarette smoked (Generic event)
• Query result output event (List generic events)

Whenever the user starts smoking, a cigarette lit event with the current date is emitted. The same way, an event is emitted when a cigarette is put out.
Additionnally, a cigarette smoked event is sent, represented by a JSON serialized version of a generic event, containing the start & end date plus some additionnal information about the smoking intensity.
The query result event is fired in response to a database query. It contains the serialized version of the query result.

Input interface

• Query All
• Query SQL
• Query for event
• Query for event since

The differents Input interfaces are used for querying the database using a specific search criterias. Additionnally, we can imagine exposing another input probe that allows for inserting events to database.

Option 1:

High added value service specified in three beans :

• First bean used to fetch information from the connected object, using the UPnP Service.
• Second bean capable of retrieving events from the user's calendar using the Google Calendar API.
• The last bean combines the information from all the other sources bean and produces a high level information showing the average number of cigarettes per day and the average time spent smoking per day, depending of how many hours the used worked.

Option 2:

High added value service as advanced data analyser:

• Beans fetching the additional information are integrated into the object
• Each data input is persisted into the internal storage as a Generic Event
• The high added value service is used to analyse the data stored inside the bean and output some “high value information”

• Dlls and wcc assemblies as installed on the phidget

• Complete project: sources, assemblies, graphs, pictures

• GUI client querying both the object and google calendar(w/o wcc composition)

• The minimal requirements for running are the presence of Mono on the embedded device, the WComp container and Beans folders, as well as one of the .wcc assemblies from the phidget.rar. The database(Events.db) is created in the shared folder the first time the application starts. Additionally midifications to the beans properties via the structural interface(at runtime) are persisted upon restarting. For the demonstration we had also prepared the autorun script(also found in the phidget.rar)

• The the WPF client requires .net 4.5 to be installed on the PC. There is also a debug display client(found within the main project sources) that could be extended to modify properties on the object at runtime.

We have had good relations with our colleague from Reims.
He was quick to respond to our questions and opened to any suggestions.
He has shown real interest about our project and he was always on time for delivering the required information.

When the prototype arrived at Nice, the product's shape and size was in accordance with our expectations, but it had some manufacturing issues :

• The top part of the product is not practical when smoking, it falls down too easily and does not includes the air quality sensor. Instead that sensor was placed inside the base of the object, giving us very poor measurements of the air quality.
  
• The base of the prototype featured some nice slots for placing the main Phidget board with good placements for screws, but there was a piece of plastic that came right in front of the sensor plugs of the main board. We had to cut it in order to plug our sensors to the motherboard.
  
• The ashtray is removable and its material is resilient to a cigarette heat, which is nice and required anyway. But its painting started to come off as soon as we started to put out real cigarettes. The overall paint also seems to remove itself easily.
  

Nevertheless we are satisfied by this experiment and by the product and we are willing to make that kind of collaboration again.

Our object could use some design improvements in order to make it suitable for a user who has been smoking for many years, like a bigger ashtray or better supports for the upper-part of the product.

In terms of sensing capacities, we could add the following sensors :

• Some contact sensors under the cigarette holders located at the edges of the the ashtray.
• Another air quality sensor inside the base of the object in addition of the sensor above the ashtray, allowing us to measure the ambient air's quality.
  

Using the sensors described above, we could allow our object to inform us about how many cigarettes were smoked at a time.
We can also add another service that returns us the quality of the ambient air around the object.
Eventually, we can also create a smarter service that returns the air quality's offset between the ambient air and the one above the ashtray.

Using the contact sensors we could make the information given to the user more reliable by ignoring the cases where multiple cigarettes were smoked at the same time.
Using the new air sensor, we could give advise the user on his exposition to toxic substances due to his smoking activity.
We could also use new providers for evaluating the environmental factors that pushes the user into smoking, like the weather forecast, the TV program, and many other services.

For our product, some good GUI for data visualization would be computer or mobile applications displaying for each day every smoking event that happened. These applications could also display graphs showing the user's activity over time or diagrams revealing to the user the environmental factors that pushes him into smoking, and those that doesn't.