Chatting about storing data into the EEPROM with @paqor I got a little bit curious what the mysensors library stores into that EEPROM so I wrote a little function for dumping that data. I tested it with the 1.4 version of the library:

void DumpMySensorsEepromData()
{
	Serial.println("Dumping MySensors EEPROM:");
	Serial.println("");

	Serial.print("Node id: ");
	Serial.println(EEPROM.read(EEPROM_NODE_ID_ADDRESS));
	Serial.print("Parent node id: ");
	Serial.println(EEPROM.read(EEPROM_PARENT_NODE_ID_ADDRESS));
	Serial.print("Distance: ");
	Serial.println(EEPROM.read(EEPROM_DISTANCE_ADDRESS));
	Serial.println("");

	// child --> route
	Serial.println("Routing information: ");
	for (int route = EEPROM_ROUTES_ADDRESS; route < EEPROM_CONTROLLER_CONFIG_ADDRESS; route++)
	{
		int child = route - EEPROM_ROUTES_ADDRESS;
		uint8_t destination = EEPROM.read(route);

		if (destination != 0xff)
		{
			Serial.print(child);
			Serial.print(" --> ");
			Serial.print(destination);
			Serial.println("");
		}
	}
	Serial.println("");

	// metric imperial
	Serial.println("Controller config: ");
	uint8_t isMetric = EEPROM.read(EEPROM_CONTROLLER_CONFIG_ADDRESS);
	if (isMetric == 0xFF)
	{
		Serial.println("is metric");
	}
	else
	{
		Serial.println("is imperial");
	}
	Serial.println("");

	Serial.println("Controller config raw data: ");
	for (int config = EEPROM_CONTROLLER_CONFIG_ADDRESS; config < EEPROM_FIRMWARE_TYPE_ADDRESS; config++)
	{
		Serial.print(EEPROM.read(config));
		Serial.print(", ");
		if ((config - EEPROM_CONTROLLER_CONFIG_ADDRESS + 1) % 8 == 0)
		{
			Serial.println("");
		}
	}
	Serial.println("");

	Serial.print("Firmware Type: ");
	Serial.print(EEPROM.read(EEPROM_FIRMWARE_TYPE_ADDRESS + 0));
	Serial.print(", ");
	Serial.println(EEPROM.read(EEPROM_FIRMWARE_TYPE_ADDRESS + 1));
	
	Serial.print("Firmware Version: ");
	Serial.print(EEPROM.read(EEPROM_FIRMWARE_BLOCKS_ADDRESS + 0));
	Serial.print(", ");
	Serial.println(EEPROM.read(EEPROM_FIRMWARE_BLOCKS_ADDRESS + 1));
	
	Serial.print("Firmware Blocks: ");
	Serial.print(EEPROM.read(EEPROM_FIRMWARE_VERSION_ADDRESS + 0));
	Serial.print(", ");
	Serial.println(EEPROM.read(EEPROM_FIRMWARE_VERSION_ADDRESS + 1));
	
	Serial.print("Firmware CRC: ");
	Serial.print(EEPROM.read(EEPROM_FIRMWARE_CRC_ADDRESS + 0));
	Serial.print(", ");
	Serial.println(EEPROM.read(EEPROM_FIRMWARE_CRC_ADDRESS + 1));
	Serial.println("");

	Serial.print("Start of local user config is at address: ");
	Serial.println(EEPROM_LOCAL_CONFIG_ADDRESS);
	Serial.println("");

	Serial.println("Local user data: ");
	for (int localConfig = EEPROM_LOCAL_CONFIG_ADDRESS; localConfig < EEPROM_LOCAL_CONFIG_ADDRESS + 255; localConfig++)
	{
		Serial.print(EEPROM.read(localConfig));
		Serial.print(", ");
		if ((localConfig - EEPROM_LOCAL_CONFIG_ADDRESS + 1) % 8 == 0)
		{
			Serial.println("");
		}
	}
	Serial.println("");
}

The output looks as follows:

Dumping MySensors EEPROM:

Node id: 1
Parent node id: 0
Distance: 1

Routing information:
0 --> 0
1 --> 1
2 --> 100
5 --> 101
65 --> 101
100 --> 100
101 --> 101
102 --> 102
104 --> 100
105 --> 105
106 --> 106
107 --> 107
108 --> 108
109 --> 109
110 --> 110
111 --> 111
112 --> 112
129 --> 101
243 --> 243

Controller config:
is imperial

Controller config raw data:
1, 255, 255, 255, 255, 255, 255, 255,
255, 255, 255, 255, 255, 255, 255, 255,
255, 255, 255, 255, 255, 255, 255, 255,

Firmware Type: 255, 255
Firmware Version: 255, 255
Firmware Blocks: 255, 255
Firmware CRC: 255, 255

Start of local user config is at address: 291

Local user data:
255, 0, 0, 0, 255, 255, 255, 255,
255, 255, 255, 255, 255, 255, 255, 255,
255, 255, 255, 255, 255, 255, 255, 255,
255, 255, 255, 255, 255, 255, 255, 255,
255, 1, 1, 1, 255, 255, 255, 255,
255, 255, 255, 255, 255, 255, 255, 255,
255, 255, 255, 255, 255, 255, 255, 255,
255, 255, 255, 255, 255, 255, 255, 255,
255, 255, 255, 255, 255, 255, 255, 255,
...

The data is from a repeater. Note that the layout may change in upcoming mysensors versions.
Your local data is for example stored at offset 291, so be careful when using the native EEPROM functions where you have to provide an offset!

@vikasjee
Everything is straight forward:

• install FHEM on a rapsberry
• add the MYSENSORS gateway to fhem.cfg

define MYSENSOR_Gateway MYSENSORS 192.168.178.20:5003
attr MYSENSOR_Gateway autocreate 1
attr MYSENSOR_Gateway requestAck 1
attr MYSENSOR_Gateway stateFormat connection

• install mosquitto on the raspberry
• add the MQTT device to fhem.cfg (point to local MQTT broker)

define mqtt MQTT 127.0.0.1:1883

• publish sensor data (e.g. MQTT_CO2) from FHEM to MQTT

define MQTT_CO2 MQTT_BRIDGE MYSENSOR_MQ135_CO2
attr MQTT_CO2 IODev mqtt
attr MQTT_CO2 publishState fhem/CO2
attr MQTT_CO2 stateFormat transmission-state

Whenever the CO2 value changes it is forwarded to the local mosquitto broker via topic fehm/CO2
Now you any client in the world that has access to the raspberry my subscribe this topic. You simply have to
know the IP address of the MQTT broker.

• install Node-Red on the raspberry
• open the Node-Red window of the raspberry <IP>:1883
• drag the MQTT input node to the sheet
• configure the MQTT input node so that it uses the local broker and the topic from above
• drag a debug output node to the sheet
• connect both
• Deploy

--> The CO2 values are printed in the debug window.

The same can be done from within bluemix with the difference that node-red runs in the cloud accessing your local broker in the raspberry.

Ok, it seems that I found the cause of the problem: after changing the radio everything works as expected:

Here the green line with sporadic wrong values:

And here the result with a new radio:

--> SOLVED

Some people asked if the library is able to control other parameters than the fan speed. The answer is yes. The following screenshot shows my sliders and buttons in FHEM:

Sorry for the german labels again:
The first group shows the power state (ON/OFF), the heating-state (winter season=ON, summer season=OFF) and the HRC damper position (inactive=OFF). See last post.

The second group shows some alerts (none at the moment)
the third group shows a button to switch between summer and winter season. The sliders control some temperature thresholds and other parameters.

If you want to have a look at the bus data yourself you can download my sniffer tool which is a .Net port of the serial library described above under valloxserial.net

see also http://forum.mysensors.org/topic/2680/data-stored-in-the-eeprom

This is a picture of the outlets and the remote control. You can see that the remote control does not have any DIP switches anymore:

The hardware setup is straight forward: the sender on the left is connected to PIN 4 and the receiver on the right is connected to PIN 3 of the arduino:

I analyzed the codes of the remote control using the "poor-man's oszilliscope" and audacitiy. Further details can be found here:
http://forum.arduino.cc/index.php?topic=201771.0

Finally I developed a library that is very similar to the rcswitch one to be able to read the codes from the remote-control.
The sketch contains receiver and sender functionality at the same time to make experimenting easier. In future there will be at least one sender sensor and one receiver in my sensor network. The receiver will be probably in my living room while the sender node will be at the other end of my mysensors network. The codes of the remotecontrol will be routed through the 2.4GHz network to the 433Mhz sender.

0. Initialisation:

FlamingoSwitch Switch; 
Switch.enableReceive(IRQ_PIN);
Switch.enableTransmit(TX_PIN);

1. Receiving codes from the remote control:

if (Switch.available())
{
    unsigned long code = Switch.getReceivedValue();
    uint32_t state = code << 4; // 28Bit --> 32Bit
    Serial.print("Detected code:");
    Serial.print(state, HEX);
    Serial.println("");
    Switch.resetAvailable();
}

As the code is 28Bit long the rest of the 32Bit number is filled up with 0.

2. Sending codes to the outlets:

Switch.send(code);

The sketch demonstrates two different possibilities of how to use the library.

1. Controller stores codes of outlets:
The sketch registers sensor 0 as custom device: gw.present(0, S_CUSTOM);
This sensor 0 is used to sniff for codes received from the remote control. It will send the detected code to the mysensors network controller. The controller can send these codes back to sensor 0 to switch the outlets. In this mode the controller needs to store the codes for the different outlets in its configuration.

2. Codes are stored in sketch:
The sketch registers sensor 1-4 as light sensor: gw.present(sensorId, S_LIGHT);
The sensor can be switched on/off from the controller. As the remote control sends 4 different codes for each button I included all of them in the sample sketch though only one of the four codes is neccessary to control the outlet.

.... to be continued

https://github.com/mysensors/MySensorsArduinoExamples/tree/master/examples/WeatherStationSensor
or
https://github.com/windkh/mysensors/tree/master/WeatherStationSensor

I will port it to mysensors 2.0 soon.

This is the original controller of the ventilation system. It displays the fan speed as well as the 4 temperatures: incomming air, exhaust air, inside temp, outside temp. You can control the fan speed level 1-8 by pressing the up and down buttons.

The controller communicates with the main device via a RS485 bus. To read the data sent between both parties I used an arduino mega as it has more than one hardware serial lines. This leads to less corrupt telegrams when communicating via RS485. You need at least one RS485 to TTL converter. As I had two of em I used one for sending and one for receiving telegrams:

I had to develop a serial library that is able to interpret the vallox protocol. The protocol description can be found here:
http://knx-user-forum.de/gebaeudetechnik-ohne-knx-eib/18274-vallox-rs485-schnittstellenbeschreibung.html

The library is used by the vallox-sensor-sketch to retrieve the data from the RS485 bus. The variables are send to the mysensors controller as different sensor values (41 different variables!).

integration into FHEM was very easy. The following picture shows the most important variables and their readings. I did not import the other ones as I do not have any original CO2 Sensor nor humidty sensors attached.

I also added some buttons to FHEM to make controlling of the vallox device easier:

Inspired by samppa I added some calculations for efficiency of the heat exchanger see also
http://forum.mysensors.org/topic/38/measuring-efficiency-of-home-air-ventilation-heat-exchanger-unit/3

The fan speed can be controlled by any tablet or phone in my house now. If somebody accidentally pushes the boost switch in the shower in the night it does not bother me any longer. I can easily turn it off using my iPhone

After some months of testing a little update:
I received some e-mails questioning the so called "heat recovery cell bypass" mode. There is a damper inside the device that can
is switched automatically by the vallox-controller to bypass the heat recovery cell (HRC) to avoid heating up the house during the
summer months. Well, when you open the device on a hot summer day you will probably see the damper in an obvious wrong position:
the air does not bypass the HRC! Huh! whats wrong here?

Explanation:
The device tries to cool down the incoming air by leading it through the HRC which is still colder than the temperature outside. If the temperature outside is colder than the air inside the house the damper is switched to the expected position. There are two things to you have to do to make all that work correctly:

• turn off heating mode (the LED of the left most button on your control device must be off)
• the HRC bypass temperature must be set to a value below the outside temperature (e.g. 14 degrees)

To illustrate that effect I logged the temperatures in FHEM:

Sorry for the german labels.
The first plot shows the damper position: blue background: HRC bypass is active.
The second plot shows the temperature outside the house (blue) and the temperature inside the house (red)

As soon as the temperature outside is greater than the temperature inside the HRC bypass is deactivated to cool the incoming air by leading the air through the "colder" HRC.

The fourth diagram shows the temperature of the air that is entering the rooms (purple) and the temperature outside the house (blue).
You can see that the fresh air entering the rooms is lower than the temperature outside: the cooling effect works (even if it is only few degrees)

To all guys thinking about how to control the damper on their own logic from a raspi or arduino. This is not neccessary as the vallox logic works very well.

For those who want to have the FHEM files here they are:
_MYSENSOR_Vallox.cfg
simply place the file in FHEM's subfolder FHEM and include it your fhem.cfg:

include ./FHEM/_MYSENSOR_Vallox.cfg

And here are the plot files which have to be placed in the subfolder www\gplot
SVG_FileLog_Vallox_6.gplot
SVG_FileLog_Vallox_5.gplot
SVG_FileLog_Vallox_4.gplot
SVG_FileLog_Vallox_3.gplot
SVG_FileLog_Vallox_2.gplot
SVG_FileLog_Vallox_1.gplot

You will likely have to adapt the room and group names, and of course the german names, sorry for that.

Note that you can make use of any MAX485 module that is suitable for the arduino (5V). Basically they are all the same except for a few minor tweaks like LEDs or other non relevant stuff.

Well basically the part list is very simple

1x Arduino Mega 2560
1x NRF24L01+
1x Pushbutton
2x MAX485 Module TTL Switch Module (one for sender, one for receiver)
(e.g. https://protosupplies.com/product/max485-ttl-to-rs-485-interface-module/)

The 1x Resistor 120Ohms is only neccessary if not already mounted on the MAX485 Module. It depends on what module
you bought. So have a look at the layout and check if there is a 120Ohms resistor mounted between pins A and B.
The module (https://protosupplies.com/product/max485-ttl-to-rs-485-interface-module/) already contains that resistor.

Optionally you can add a capacitor between + and - to stabilize the voltage level if your power supply is a weak one.
Anyone will do like 10uF, 100uF...

Ok ... after my holidays.

Hi @captaindork
sorry for delay,.... the position of the damper (which is the bypass) is indicated through a single bit of the multi purpose IO-Port 2. The library defines that as property 38 DamperMotorPositionProperty.
In the mysensors example it is published as
const uint8_t DAMPER_MOTOR_POSITION = 42;
The value is either 1 or 0.

I mapped it in FHEM as follows

attr MYSENSOR_Vallox mapReading_DamperMotorPosition 42 value1

define MYSENSOR_Vallox_DamperMotorPosition dummy
attr MYSENSOR_Vallox_DamperMotorPosition alias WRG-Bypass
attr MYSENSOR_Vallox_DamperMotorPosition devStateIcon 1:rc_GREEN 0:rc_BLANK
attr MYSENSOR_Vallox_DamperMotorPosition event-on-update-reading state
attr MYSENSOR_Vallox_DamperMotorPosition group Status
attr MYSENSOR_Vallox_DamperMotorPosition icon vent_bypass
attr MYSENSOR_Vallox_DamperMotorPosition room Lüftung
attr MYSENSOR_Vallox_DamperMotorPosition sortby 3
define MYSENSOR_Vallox_DamperMotorPosition_Notify notify MYSENSOR_Vallox:DamperMotorPosition:.* { my $d = sprintf ("%.0f", ReadingsVal("MYSENSOR_Vallox","DamperMotorPosition", 0));; fhem("set MYSENSOR_Vallox_DamperMotorPosition $d");;}
define MYSENSOR_Vallox_DamperMotorPosition_Notify2 at +*00:01:00 { my $d = sprintf "%.0f", ReadingsVal("MYSENSOR_Vallox","DamperMotorPosition", 0);; fhem("set MYSENSOR_Vallox_DamperMotorPosition $d");;}

@sm_ali
You can have a look at this lib here
https://raw.githubusercontent.com/DFRobot/DFRobot_BME680/master/bme680.c

there is code that handles the calib thing

@neverdie yes that is the plan

@neverdie same with me. I gave up using the BME680 for the same reasons you have. It is cheap and offers 4 readings in one chip but can not be really used with a small microcontroller like arduino nano or the sensebender micro as Bosch does all the drift compensation using software that requires large memory.
I believe theis chip was meant to be used in smartphones instead of homeautomation sensors.
I will order a SGP30 today. Thanks for pointing into that direction...
Gr Heinz

@alexsh1
No I am not using the BSEC library. I read the raw values of the resistance and calculate the first derivative for triggering the ventilation system. The ventilation system is turned on, when
(delta resistance)/minute > threshold

Sometimes the ventilation is also triggered when I open my fridge. Then the smell of food coming out of the fridge also fires the trigger.

It is said that the sensor is very sensitive to any kind of silicone which is basically everywhere in the air when you have dishes created from silicone in your kitchen. Silicone poisens/blinds the sensor immediately for several hours.
So be careful when making experiments with it.

I like the BME680 sensor as it has a very low power consumption. But it has also some disadvantages that have impact on the application and the environment it should be used.
As far as I know the sensor was developed to be used in mobile phones or smart watches. Those devices are exposed to "fresh air" almost every day which makes it possible to estimate the air quality from the resistante of the sensor. The resistance of the sensor increases over the weeks and months as the internal chemical layer is exhausted or used up depending on the environment it is exposed to. The fading of the resistance can be compensated through smart algorithms that work on historical data (see post above). When the sensor is exposed to "fresh air" once a day, the algorithm can use this value as a kind of reference value to estimate the air quality index.
But if you want to use this sensor for indoor applications, where the environment is very constant or changing very slowly, then I doubt that the algorithm is able to calculate an exact value for the air quality index.
Knowing this means that you can use the sensor resistance also without the BSEC library and with your own simplified algorithm when "recalibration with fresh air" is done sometimes on your own. Another useful application could also be an outdoor weather station where the sensor is exposed to fresh air most of the time.
All in all it is a cool product as it offers other measurements, too which spares hardware and minimizes the costs. In addition to that you can change the meaurement parameters of the sensor on your own as a good user manual of the sensor is also available.

I am using the sensor in my kitchen to detect when someone is cooking. In this case I am not interested in the absolute resistance, but in the change over time. If the air quality gets worse in a very short time (resistance change per minute), then I can activate the ventilation system. The same could be done on the toilet

best regards Heinz

Studying the log files of the night I found one damaged value

2017-11-04_23:02:43 MYSENSOR_BME680_R 33597 Ohm
2017-11-04_23:02:53 MYSENSOR_BME680_R 33760 Ohm
2017-11-04_23:03:04 MYSENSOR_BME680_R 33814 Ohm
2017-11-04_23:03:25 MYSENSOR_BME680_R 33705 Ohm
2017-11-04_23:03:25 MYSENSOR_BME680_R 2164818857 Ohm
2017-11-04_23:03:36 MYSENSOR_BME680_R 33814 Ohm
2017-11-04_23:03:46 MYSENSOR_BME680_R 33869 Ohm
2017-11-04_23:04:07 MYSENSOR_BME680_R 33624 Ohm
2017-11-04_23:04:49 MYSENSOR_BME680_R 33924 Ohm

Well, exchanging the radio improved the situation significantly, but unfortunately the problem might be still there....