eLDERmon  EnOcean Sensors

 

This post follows my last posts on sensors, and integration into openHAB

 

Link to other posts
Forget Me Not : eLDERmon Intro
Forget Me Not :  eLDERmon  Electrical
Forget Me Not :  eLDERmon  Outlets
Forget Me Not : eLDERmon Planning
Forget Me Not : eLDERmon Parts 1
Forget Me Not :  eLDERmon  Sponsor Parts
Forget Me Not : eLDERmon Hardware Hacking
Forget Me Not : eLDERmon GNUplot
Forget Me Not: eLDERmon Protocol
Forget Me Not : eLDERmon Hardware Hacking #2
Forget Me Not : eLDERmon Hardware Hacking #3
Forget Me Not : eLDERmon Tim
Forget Me Not : eLDERmon Charts
Forget Me Not : LPG Level
eLDERmon EnOcean Sensors
eLDERmon EnOcean Sensors Part 2

 

I managed to work out that these were the settings that openHAB could use

{ enocean="{id=00:83:1D:FA, eep=A5:07:03, parameter=MOVEMENT}" }

{ enocean="{id=01:81:7B:88, eep=A5:07:03, parameter=ILLUMINANCE}" }

 

and I changed the configuration to reflect this, fired it up and

 

 

It seems that no matter what I did, the STM310 would not allow a variable setting.

 

 

 

FIRMWARE

After consulting the EnOcean manual for the STM310 and the STM330 it became apparent that they use the same hardware.

The STM330 manual states

    If you want to connect other generic sensors to STM 33x (former STM 310 applications), you can download STEMSEN Software from following link: http://www.enocean.com/en/download/


So armed with that information I did some other checks


STM310_features.PNG  STM330_features.PNG

                    STM310 Features                                                                                                        STM330 Features


So it seemed that you could program a STM310 with STM330 firmware and providing you didn't want a calibrated Temperature Sensor, it should work.



The next problem was what profile to program it with.

Looking at Dolphin Studio, under STM330 you have the following :-

STM330_options.png


None of these align with openHAB A5-07-03


The manual (Ver 1.15) shows a different version of Dolphin Studio and has these options

Studio_options.PNG

              STM330 Ver 1.15 Page 20


Since our version and the manual don't match, that wasn't going to help me.



If you check the manual, it shows the connections for the Set point and Occupancy Control


SetPoint.PNG

                    Set Point and Occupancy connections (page 25)

and from the manual

ADIO_0.PNG

OCC.PNG

 

This gives me some connection points,

If you look at profile A5-10-05 it allows for Temperature, Set Point and Occupancy

Illumination_sensors.PNG

 

At this stage there was little to lose, since I'd spent a lot of time already and didn't want to resort to external devices.

 

 

Test

I decided to program 2 units, and I hedged my bet and programmed  them differently, just so I didn't need to stop and start openHAB.

 

I' happy to report it worked, and I could obtain a reading, which also updated at regular intervals.

The results were as expected, considering they were on the programmer with a fixed value to simulate the LDR.

LivingLight_plot.png

          I massaged this image to include both labels

 

As the graph shows, the 'raw' Light level reading is large compared with the temperatures, and while the graph scales, it will not show what I wanted.

 

I could either use hardware and adjust the range using a few resistors, or add a rule.

 

I searched and struggled with the correct syntax for the rule to work  ...  for far too long.

Since I'm not a software guru, I was getting stuck.

 

In the end I reached out to fvan who came back very quickly with the required code ..... so it looks like I owe him big time.

 

rule "Update Living Light Level"
when
    Item Living_Light_Level received update
        then
        var new_Living_light_level = Living_Light_Level.state as DecimalType
        var modified_Living_light_level = new_Living_light_level.floatValue/20
        postUpdate(Living_Light_Graph, modified_Living_light_level )

end



 

The value is divided by 20, to give a much better picture, when coupled with the cause.

LivingLight3.png

While this is artificial, it shows the movement, and then the light level change as a result of the movement.

ie Granny is up and has opened the curtains. 

 

Ignoring the times in this simulation, we can check if was earlier or later than normal, but we can see that it was good light (ie not a cloudy miserable day), and we can expect the temperature to climb.

 

 

Sensor connection

For my testing I have simply used the EOP350 programmer.

I connected a jumper across the WAKE0 (STM 3xx pin 2) to GND (pin 5) and set the firmware for a 'falling edge' trigger.

A variable resistor wheel between ADIO0 (pin 9) and SWPWR (pin 8) simulates the LDR and I fully expect the range to change.

 

For my application, I'm not after accurate figures, just a reading that is meaningful.

 

Best of all this one is self powered.

 

 

Mark