Showing posts with label ask. Show all posts
Showing posts with label ask. Show all posts

August 13, 2014

New Firmware and Manual for the WMS Mk2

Just before the summer vacations I finalized the Wireless Multi-sensor Mk2 firmware that I have been working with for quite some time.

News,

  • CO2 sensor S8 from SenseAir is now supported. It can be connected to the Event Input after changing the input mode of the Event Input (c.f. Manual). You can get the CO2-sensor here.
  • MAX31850K support. This chip is a Thermocouple Type K to 1-wire chip. This makes it possible to make a Type K thermocouple wireless. It can output 409.6°C as the highest temperature. It is a limitation set by the protocol I use. Here you can find a MAX31850K-module, m.nu.
  • DS2450 support. This is a 4 channel AD converter. All 1-wire sensors based on this chip will be compatible with the WMS Mk2. This,  this, this, this and this is also compatible modules since they are based on the DS2450 chip.

Improvements,

  • Events are now sent as a LMST-606 device. An ON or OFF signal will be sent depending on if the input pin is pulled up or pulled down.
  • The Manual is out in a first revision.

All Wireless Multi-sensors Mk2 will be shipped with this new firmware from now on.

May 13, 2014

The Wireless Pulse Counter will take over from the old Wireless Energy Meter

EDIT (2014-09-21): I have added RFXMeter compatibility so that the WPC will show up as a RFXMeter and thus be natively supported in Domoticz. Available in WPC sold from this date. Here is an instruction for how you configure it in Domoticz.

EDIT (2014-09-15): Added information about support for the LED-pulse detector from m.nu.


The old Wireless Energy meter serves its purpose, but it has a few shortcomings.

Here is a new product that I call Wireless Pulse Counter (WPC). This is a better name compared to the old Wireless Energy Meter, since it is actually only counting pulses, not energy or liters.



Since it is only counting pulses it is also much more versatile.

  • You can combine the WPC with a reflex detector (TCRT5000) and measure water flow, gas consumption or electric energy consumption if it is of the rotating disk type.
  • You can count the amount of blinks from an Electric energy meter. Both LED and S0 output is supported.
This is how you connect the WPC to a S0 interface. The current through the S0 port need to be limited.
A resistor value of R=330Ω is OK.
The LED-pulse detector from m.nu is very very sensitive. The sensitivity can be reduced by adding a resistor R between S0- and GND on the WPC. A value between 820Ω and 4k7Ω seem to be reasonable values. Lower value => lower sensitivity.

From the counted pulses you can then calculate the consumed water/energy/gas/events etc.

The new WPC will fit perfectly in a plastic box from Hammond, with the dimensions 20x35x50mm. Note! I have not decided on a box with or without flanges as in the pdf.



The power feed is changed to a micro-USB instead of a mini-USB connector. In this way you will very likely already have a power source for it. You can just reuse an old Android-mobile charger to power it.

Most people do not have a soldering station at home. This version comes with screw terminals so that a  soldering station will never be needed.

It is professionally assembled with perfectly soldered components.

Further more, I have changed the protocol to a simpler variant. All credits to Stefan Strömberg at OpenNetHome for this suggestion.
With this new protocol you can drop several packages. Lots of packages. Still, even with only a few packages received, you can trust that they reflect the consumed energy. The solution is utilise the Humidity data field as counter data in the same way as with the temperature data field. In this way it is possible to have an always increasing counter.
It will wrap around, but the maximum counter value will be so big so that there will need to pass several hours of lost packages to mess up the energy logging.

Note that in the normal case you do not loose many packages, so the above text describes the extreme situation.

As soon as I have finished the verification of the hardware, I will make it available in the foogadgets store.

EDIT: It is now available in the web-store foogadgets.tictail.com.

January 8, 2014

Wireless Energy Meter

Hi again,

In our croft (summer house) I can turn on and off a couple of radiators just by sending an SMS. This is very convenient in the autumn to spring time. If we plan to visit the torp i just send an SMS some hours before our ETA, and that is all it takes to have a warm comfortable summer house to arrive to.

But I also wanted a way to measure the energy consumption in some way. From the electric meter in the barn to the torp where the logging computer is located, it is about 40 meter. And I really did not want to dig down a cable from there into the torp. Wireless would be so much more convenient.

Since I already had the Wireless Multi-sensor I figured I could reuse parts of the code and use the same PIC12F675 micro controller. I could not use the same multi-sensor since it was too crowded among the input/output pins. I had to start all over with a new device.

The electrical meter have a LED that blink 1000 times/kWh, but there are also electrical meters that blink 10,000 times/kWh. My Wireless Electrical Meter is however not dependent on the amount of blinks per kWh since the calculations is done in scripts on the receiving side (received by a tellstick or rfxtrx433) and are thus adapted there to the right blink frequency. Examples will follow later in this post.

This is the kind of Electric meter I have in our croft.

This is a close-up of the blinking LED:s. It is only the lower LED in this case that is interesting. That is the consumed energy that I pay for.


It is however important to know that this Wireless Energy Meter is only sending the detected amount of blinks as a temperature. It does not do any calculations or generate any timestamps locally on the device itself.

The Wireless Energy Meter phototransistor (looks like a LED) need to be mounted face-to-face to the blinking LED on the electrical meter. Care should be taken so that as little light as possible is exposed to the phototransistor, as this can generate false detections.

Once mounted and powered, it will start to send the data approximately once every minute.

Viking temperature/humidity sensor

The Wireless Energy Meter is seen by the Tellstick DUO or Rfxtrx433 as two separate Viking temperature+humidity sensors. Both sending data synchronous once every 60 seconds (approximately).

The primary Viking sensor is sending the last minutes number of detected blinks from the energy meters LED. The secondary Viking sensor is sending the penultimate minutes number of detected blinks.

The temperature that is sent is the amount of detected blinks divided by 10. So for example if the Wireless Energy Meter have detected 342 blinks it will send this as a temperature of 34.2°C.


Here is the PCB. The size of this PCB is 50x50mm.

This is the side that should face the Electric meter. The PT1 is the phototransistor that detects the blinks.

This is the back. The size is compared to 1 Swedish Krona. The PCB is 25x25mm but the TX433 transmitter builds 13mm on the side.

The humidity field I use as a data package number that increases from 0 to 99 and then wraps around. The humidity data can thus be used on the receiving side to detect if there have been any lost packages. If one detect a lost package on the receiving side one can recover the lost data by using the secondary sensors data since this is the penultimate data. For this reason, once every minute I send the penultimate data first, followed by the most recent data. In this way I will be sure to already have the penultimate data available when the most recent data is received. It is first when I get the most recent data I can detect if I need to recover.

Since this device is only sending raw counter data, it will be compatible with many home automation applications such as Beyond Measure, Switch King, Automagically, tellmon.net or any other solution used.

This flexibility come with a drawback. It is very much up to the user of this device to implement the code on the receiving side, to get a complete solution. I will in this blogpost share some of the algorithms and scripts that I have used.

Logging

The most interesting part of the energy reading activity is the logging. Then you can actually see the history of the energy consumption and correlate that to the inside and outside temperatures. You can also possibly detect any energy hogging device by looking at the periodicity of a peak power usage.

For this Wireless Energy Meter I first tried RRD (rrdtool). The RRD is the round robin database that is very good to use when you need to limit the size of the database. One of the drawbacks is that you need to specify at the time of creation, with what periodicity you will log your data. My sensor is sending new data once every 60 seconds ... approximately. I use the internal oscillator to clock the sleeping time of the PIC. The internal oscillator is not very accurate. The accuracy should however be within 60s +-2s. This will of course affect the accuracy of the energy calculations. The clock is also dependent on the surrounding temperature.

A better way to log the data is to use a SQL-database. Then you can save the timestamp of the data at the time of arrival, and then do calculations based on the counted pulses and time passed since last the previous package was received.

The following algorithm can be used to detect lost packages and also log to a database. See it as pseudo code,

// Callback function (If it looks similar to Telldus it is because it is based on an example from them)
void sensorEvent( int sensorId, const char *value, char *temp) {
  if ( sensorId == 69 ) { //Store the secondary virtual sensor value
    f_temp[sensorId] = atof( temp );
    i_seqno[sensorId] = atoi( value );
    return;

  } else if ( sensorId == 68 ) { //Store the Primary virtual sensor value
    f_temp[sensorId] = atof( temp );
    i_seqno[sensorId] = atoi( value );
    i_diff[sensorId] = i_seqno[sensorId] - i_prev[sensorId];
    switch ( i_diff[sensorId] ) {
      case 1:
      case -99: // All OK
                // Log f_temp in a MySql-db or send it to Xively for example.
      case 2:
      case -98: // One transmission lost. Check if we can recover.
        if ( (i_seqno[sensorId]-i_seqno[sensorId+1]) == 1 ||
             (i_seqno[sensorId]-i_seqno[sensorId+1]) == -99 ) {
                // It seem like we can recover. Log the f_temp[sensorId+1] and the f_temp[sensorId] value.
        } else {
                // If we are here, we have lost one transmission and can not recover. Anyway, we log the current value f_temp[sensorId] and do a best guess of what the lost value was. We could use an average number or the same as current value f_temp[sensorId]. This would likely be less wrong than leaving it empty.
        }
        break;
      default : // If we are here we have lost more than one complete transmission. If this occur frequently you have to look over your setup.
    }
    i_prev[sensorId] = i_seqno[sensorId];
  }
  return;
}



The formulas for total consumed Energy (Wh) and the current Power consumption (W), goes something like this,
TotalEnergi = Start_value + SUM(temp*10)/1000
The Start_value is optional and can be used when starting the measurements. You get it from the display on the electric meter. If you add this you will hopefully get the same numbers in the graphs as on the electric meter. The Start_value should be given in kWh. TotalEnergy is kWh.
SUM() is the sum of all incoming "temperatures". In C++ it would be written sumkWh += temp*10/1000;
Result in kWh.

Pmom = temp*10/1000*60* 60/(Time_now - Time_previous)
temp is the incoming data from the Wireless Energy Meter.
60/(Time_now - Time_previous) is a compensation factor that need to be added to compensate for the low precision oscillator in the PIC. The oscillator frequency depends on temperature and voltage. It is wise not to skip this compensation factor.
Result in kW


It can also be used in Domoticz. See this thread over at temperatur.nu.
Also check in Automagically and Tellmon.net that have native support for my Wireless Energy meter.
Further more, there is also a plugin for Beyond Measure, see this thread.





If you like it, you can also buy the Wireless Energy meter here, http://foogadgets.tictail.com

January 3, 2014

New version of the Wireless Multi-sensor PCB

Here is my latest version of the Wireless Multi-sensor PCB (Version 1.1).

Last night I assembled 12 units. I only had time to test two units very quickly, but all is sound so far. The only missing part is the PIC12F675. I have been waiting since 12th November :(. It will arrive any day now :)

As can be seen in the picture below, there are three inputs. One for the DHT22, one for the 1-wire bus and one event sensor input. The event sensor-input have the same pin-configuration as the PIR-sensor HC-SR501.
I have also added a power supply input (marked BAT) to the right of the DHT22 input where you have the possibility to add your own power supply.

The changelog for version 1.1,
  *A pull-down resistor can be soldered in the spot marked R4. It will not needed if the input is not used since there will be a jumper grounding the data input pin.
  *The 2.1mm DC-jack has been exchanged to a mini USB type B connector. I have also added the possibility to add your own power supply.
  *The hardware bug has been corrected.