pinae / aevoc Goto Github PK

Hi Pina,
sorry for my code reading ;-)

Pointer char* fullTopicStr is only valid in this function and points to allocated memory that is to be released again in this function with free(fullTopicStr).

void subscribeToTopic(const char* topic, void (*callback)(char*)) {
    if (!wifiIsConnected || !mqttClient.connected()) return;
    char* fullTopicStr = createFullTopicStr(topic); // <--- pointer *fullTopicStr is valid only in this function/method
    mqttClient.subscribe(fullTopicStr);
    SubscribedMqttTopic* newTopic = new SubscribedMqttTopic(fullTopicStr, callback);
    SubscribedMqttTopicList* newTopicListElem = new SubscribedMqttTopicList(
        newTopic, subscribedTopicsList);
    subscribedTopicsList = newTopicListElem;
    logger.printf("Subscribed to MQTT-topic: %s\n", fullTopicStr); /* <--- after this line, add */ free(fullTopicStr);
}

Hi Pinae,
just one remark/idea, wouldn't it make sense to improve the life time of the SDS011 sensor.
Up to it's specification it will only last 1 year if it's running in continuous operations.
Maybe it would make sense to only wake up the sensor every 2-3min read the values and put it to sleep again?
Just an idea to make the setup more sustainable.
Didn't had a chance to adjust the code by myself to meet that requirements.
Cheers /
Andreas

Hi Pina,
sorry, i don't know how to reopen a closed issue (#6).

The ERROR IS NOT FIXED!

The code "(fullTopicStr + topicLen+1) = '\0' writes 1 Byte behind the allocated memory!
Allocation code: "char* fullTopicStr = (char*) calloc(topicLen+1, sizeof(char));"
The management data of the pool or other important data may already be stored there.

Example: topicLen = 20:
-> 21 Bytes are allocated (from Byte *(fullTopicStr+0) till *(fullTopicStr+20) or *(fullTopicStr + topicLen))
-> "(fullTopicStr + topicLen+1) = '\0' writes at Byte 21 behind memory at pointer *fullTopicStr
-> my proposal for line 78: fullTopicStr[topicLen] = '\0'; or *(fullTopicStr + topicLen) = '\0';

Best regards Walter

PS: calloc() clears all bits in the allocated memory. The ending '\0' does not have to be written ;) ... behind the allocated memory

Hi Pina,
I think the buffer for deviceName in configHelpers.h is too small:
char deviceName[23] = {'A', 'E', 'V', 'O', 'C', '-', 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};
It should be:
char deviceName[25] = {'A', 'E', 'V', 'O', 'C', '-', 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};
becaus in configHelpers.cpp the zero's are overwritten with an 18-character long string,
but there is only space for 17, and no space for a trailing \0:
DeviceName::DeviceName() { byte mac[6]; WiFi.macAddress(mac); char macStr[18]; sprintf(&macStr[0], "%x:%x:%x:%x:%x:%x", mac[0], mac[1], mac[2], mac[3], mac[4], mac[5]); strncpy(&deviceName[6], macStr, 18); }

Second issue here. Shouldn't it be:
sprintf(&macStr[0], "%02x:%02x:%02x:%02x:%02x:%02x", mac[0], mac[1], mac[2], mac[3], mac[4], mac[5]);
so the string will always have 18 characters, independent from the mac?

Uwe

Dear Pina,

thanks for this great project, I really enjoyed it!
So, I kept going on and, by now, my AEVOC is still not mounted in a box but I added a real CO2 sensor and changed the code to work for me and also followed your suggestion and set up an mqtt/node red on my "NASPI" (raspi 4), so I can follow the evolution of the recorded data over time.

Now, I just wanted to comment on my findings of those: unfortunately I find the VOC sensor quite sensitive to any kind of organic molecules, odor.. we have a cat, but also cleaning the flat, drying loundry in the same room, cooking..makes the VOC shoot up. But since CO2 is only guessed, based on the VOC value, this CO2 value is not really reliable. So I added an MH-Z19 CO2 sensor and now I would say this is a really good help to judge about aerosol concenration indoors.
A problem with the particle sensor is, that it detects any particles with a certain size. That means, since a while it is a really good pollen detector ;) Which is actually good for me, because if during mornings room venting the particle count shoots up while CO2 goes down, I know I should take some anti-allergy medication before leaving the house.

Altogether, this is a real fun project with much more functionality - but the interpretation of measured values requires always some thinking, too.

Just a comment about the MH-Z19: I'm a crappy programmer and didn't work much with arduino like devices, so far.. first, I didn't manage to make it run when connected to the free pins D0 as RX and D1 as TX using softwareserial, so I took the pins D9 and D10 using softwareserial and a driver i found on the arduino website. This made debugging my code a bit tricky because this blocks communication with my pc.. If you had an advice here? Are there alternative pins allowing to communicate via UART without blocking the communication via the usb-rs232 interface?
Another problem is, that sometimes communication with the CO2 sensor is lost, so I needed to add another check-if-alive-otherwise-reinitialize to make it continously working.
Still, it was worth it: the sensor works quite excellent!

Well, thanks for all this!
I'll keep following you all on c't and c't uplink.

best
Chris

Hi Pina,

mqtt.cpp line 78: (fullTopicStr + topicLen+1) = 0; // <-- the 0 is OUT OF ALLOCATED MEMORY!
see allocation at line 74: char fullTopicStr = (char*) calloc(topicLen+1, sizeof(char));

proposal for line 78: fullTopicStr[topicLen] = '\0';

Best regards
Walter

There is no a step-by-step at Make Projects: https://makeprojects.com/de/project/aevoc

The project does not exist (any more).

Would appreciate re-upload or other means to access.

Hello Pina,

at first thank you very much for AeVOC. Works great and had a lot of fun building it.
However I have to admit I used a 3D Model for FDM printing as a housing.

Now to the topic.
At first I got no reading from the CCS811 and I was wondering if this has something to do with the Burn In mentioned by you and the Datasheet (https://cdn.sparkfun.com/assets/learn_tutorials/1/4/3/CCS811_Datasheet-DS000459.pdf) from sparkfun.

I found a specific page (https://wiki.keyestudio.com/KS0457_keyestudio_CCS811_Carbon_Dioxide_Air_Quality_Sensor) for my sensor pcb and it seems like the WAKE pin needs GND in order for CCS811 to work. At least now I get measurements.

Now I'm wondering if this is necessarily just for my CCS811 or for all of them?

Best wishes,

Sebastian