eLDERmon EnOcean Sensors
This post follows my last posts on sensors, and integration into openHAB
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 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 :-
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
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
Set Point and Occupancy connections (page 25)
and from the manual
This gives me some connection points,
If you look at profile A5-10-05 it allows for Temperature, Set Point and Occupancy
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.
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.
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
Top Comments