xapmcs1Wire.exe huge counter increase error

[tonlof]

I have moved my installation to a new computer.

I have everything working but 10-20 times in hour the watt counter increase with for example 2424509440 extra.

xapmcs1Wire.exe version 3.0.4.0

In same time that the counter increase i can se follow error in the hub.

ap-header
{
v=13
hop=1
uid=FF.0005:00
class=Homeseer.Event
source=mcs.OneWire.ITHEMMET
}
Event.Log
{
Time=4/29/2011 8:43:47 PM
Type=xapmcs1Wire
Data=Sensor 770008000B9B4410 (Ute_Skugga) Error during putByte(), echo was incorrect  at 320
}



xap-header
{
v=13
hop=1
uid=FF.0005:00
class=Homeseer.Event
source=mcs.OneWire.ITHEMMET
}
Event.Log
{
Time=4/29/2011 8:44:59 PM
Type=xapmcs1Wire
Data=Sensor 700000000C89F51D (Today) OneWireContainer1D-device not present at 340
} 

Any clue?

[Pete]

I've had similiar issues with the HB dual counter for my water meter.

The large (incorrect values) shut down my database. I ended up adjusting the values back to zero or a manageable integer.

I have to look it up on the forum every time I've adjusted it. Its a tweak in the INI file.

[tonlof]

I delete xapmcs1Wire folder and download the latets .net version but the problem starts right away after it found the devices.

[Pete]

The number doesn't go away. It's wasn't really obvious in the calculations relating to the INI for me personally. I just knew the number was so large that the DB stopped inputting.

Do a quick search for the dual counter / water meter thing. It will show you the positions of each value and what they mean in the INI file.

Here is the thread that gives an explaination.

http://board.homeseer.com/showthread.php?t=138535

[Michael McSharry]

The rates are computed as a moving average with the weighting function for the sluggishness of rate being a user input. The pseudo-code calculation is...

SecondsSinceLastSample = NowSeconds - PriorSampleTimeInSecond
Rate = (CounterCurrentSample-CounterPriorSample) / SecondsSinceLastSample * 60 * 60 'per hour
SmoothedRate = PriorRate * UserWattageWeight + (1 - UserWattageWeight) * Rate

If SecondsSinceLastSample is a small number then the instantaneous rate will tend to be large. If you do not weight it to allow smooting then things will jump around if there is any variabilty in the actual experienced sample intervals.

The user input will be a number between 0 and 1 where a value of 0 will mean no smoothing and "noisy" rates produced on the output. In my case I use a value of 0.2 and have a sample period of 15 seconds on the wattage counter.

The sample period is only significant if your overall 1-wire rates are setup to be able to maintain constant intervals. If you have your sampling rates are too high to be maintened with the bandwidth of the 1-wire bus then you introduce variabilty which could cause erratic sample intervals and then this affects the apparent rates if not adequtely smoothed.

The items that Pete was describing has to do with the wraparound on the counter. A 32 bit counter should not wrap around very often even at the full rated counter input speed of what I recall to be in the 50 Hz range. The intervals you are describing about experiencing excessive wattage rates seem to be too frequent to be described by a wraparound effect.

[tonlof]

Thanks all, I think I just solved it.

Do not do 2 change at same time It's hard to follow up the problem...

I forget that I also moved last temperature sensor in the onewirenet to another place and forgot to remove the connection from the second last temperature sensor. So I think I get a termination problem with the cable without sensor.
So this time there was a hardware miss from me, sorry for taking your time.

It has run stable for over one hour now. No error in hub and no problem with the counter.