Author: carlosmartell97

Year 2038 Problem

--Originally published at TC3045 Software Quality and Testing

Previous week was a bit slow, we lost a bit of the energy that had us so pumped up at the beginning
of the semester, but we still want to see this project through. We still believe in it. Personally, I did
some research into the “Epoch” time, an universal reference to know the current time… the amount
of seconds that have elapsed since January 1, 1970 (midnight UTC/GMT), without counting leap
seconds. And, interesting fact, many Unix systems store epoch dates as a signed 32-bit integer,
which might cause problems on January 19, 2038 (known as the Year 2038 problem or Y2038).
Beware, world. You can read more into this here https://www.epochconverter.com/


Anyways, we decided to use this system as a timestamp for every temperature reading in our
project, so I found out how to obtain this value in Python. It’s actually pretty easy. We also decided
to move forward with our initial idea of having the plant “tweet by itself” updates on its current
condition.


Next post coming soon.



Plans for Week 7

--Originally published at TC3045 Software Quality and Testing

Personal plans for this week… create a system with which the plant will periodically tweet updates on
its condition, update our sensors platform documentation and work on some ideas for automating even
more the platform so that its setup and deployment is as painless as possible.


More posts to come! until then, here’s a cool “twitter bot” I found:
image obtained from http://vivekbhat.me/


Next Week?

--Originally published at TC3045 Software Quality and Testing

Aaand another post where I forgot to hit PUBLISH. What a wonderful surprise. Well, better late than
never, as they say. To put you into context again, the following content is originally from february 19,
week 6.


What are our plans for next week, you say? I myself aren’t sure of that either. The entire last week one
of our teammates was missing, so we’ll start the week by letting him know our latest changes, and
resynchronize so we can continue moving forward. But we certainly first all need to catch up with each
other. The good thing is there have been no major stepbacks recently, so we’re mostly where we had
planned to to be.


Stay put for more updates.


I couldn’t think of a good picture for this post, so here’s a beautiful sunset



Sprint Demo 2

--Originally published at TC3045 Software Quality and Testing

Wow, long time no see. For some reason my brain forgot to post this when I should have. After just
checking right now, I realize I never actually clicked PUBLISH. Well, here it is now. This content is
originally from february 18, week 6.


This week was our second sprint review, where all of us showed each other how our projects are going,
what improvements we’ve made since the first demo and what we have planned for the next few weeks.
In our case, that mainly meant showcasing our infrastructure in Kubernetes as a public service our
Raspberry Pi can communicate to. We showed how easy Kubernetes makes it for us to decide how to
split the workload between multiple instances, as well as our new sensors all working, but only sending
through our pipeline temperature readings.




Once again, this was a good chance to see what the other teams have been working on, and look at
our project in a way we can explain it to ourselves and other people.

Rafcoitreng… Refactoring

--Originally published at TC3045 Software Quality and Testing

So… as you may know from my previous post, 2 new sensors have been added to our platform. Nice.
However, the code for this could be refactored a bit so it works in a nicer, more straight forward way.
So, this week I’ll work on improving this code and making it flow better. Also, as most weeks, we’ll
continue merging each of our individual work into a working build, getting closer and closer to a bigger
demo for our project.


We’ll see how it all goes. That’s all I have to say for now, keep an eye out for further updates.


Let the refactor begin...



Temperature, Humidity and Light

--Originally published at TC3045 Software Quality and Testing

Another week gone by. And for that, I’m here once more to update on our progress.


In this occasion, I managed to stick to this week’s goals of using a sensor that measures both humidity
and temperature, as well as adding another new sensor that measures light intensity. According to our
research, all these variables are very valuable metrics for remote plant monitoring. Now our circuit
looks a bit more confusing, but we’re still trying to stick to only the necessary components.




And that was mostly it, we also continued to organize our workflow and priorities as new issues arise.
All while making sure we don’t block each other.

Stay tuned for more updates.

New Sensors, More Data

--Originally published at TC3045 Software Quality and Testing

Hey.


As you may know from my previous post, this week I’m going to focus on using a new sensor that will
help us measure both temperature and humidity at once, as well as adding another sensor that will
help us measure light intensity. This way, we’ll have even more data to process and analyze for
remote monitoring. This will all be added to the list of pending signals to be sent over HTTPS protocol.
For now, simply reading this data and sending it over to our Broker should be enough.



That’s all for now. Bye.

Time Flies

--Originally published at TC3045 Software Quality and Testing

Hey there, again. So, 4 weeks have gone by already… time does fly. Also, now partials are here, but
let’s not talk about that now.


Or just as Michael Altshuler says, “The bad news is time flies. The good news is you’re the pilot.”




And with that being said… looking back at week 4, it was a pretty calm week. It turns out I did some
research into what has to be done so that the signals sent from the Raspberry reach out Broker with
the HTTPS protocol, and I’m pretty sure I’ve found a way. But, this HTTPS protocol must also be
enabled on our server, on a separate port. So, I’m going to have to hold on to that idea until actual
support for it is added on our server.


Other than that, I did some more research into incorporating more sensors to the platform, and it
seems that we can use a “humiture” sensor, which measures both humidity and temperature. 2
sensors in one, that’s awesome.

That’s all for now. See you later!

Plan for Week 4

--Originally published at TC3045 Software Quality and Testing

So… week 4. Past our first demo. What’s there to do right now?
We’ve gotten to a point where everyone in our team pretty much knows what the next steps are, and
what we should individually do.


Most importantly, this week we’re looking forward to merge our working pieces together and see how
it all fits. I also want to look at the security aspect of our Raspberry Pi signals, by using a certificate
to send the signals over HTTPS, and keep adding more tests for all this to be rigorously taken into
account.



image obtained from https://blog.testfort.com/wp-content/uploads/2014/12/q3.jpg

I think that’s it for now. We’ll see how it all goes.

Sayonara!

Demo. Building Stones.

--Originally published at TC3045 Software Quality and Testing

This week was cool. We officially did a sprint demo for each of our respective projects, and it was a
good chance for us to discover what everyone else was working on, and give feedback to one another;
it even was a chance for us to think about our project in a way that we can explain to other people, in
terms of our infrastructure, logic and implementation.


In our case, we were able to demonstrate the Raspberry Pi working with a temperature sensor and
sending those signals, locally, to our HTTP Broker. It was what I personally wanted to accomplish
this week. From here on, we’ll be able to continue iterating upon what we’ve done so far, with short,
trackable deliverables.


I feel our workflow progressing, making results as we go. I look forward to this project and what we’ll
accomplish.



Bye. For now.