Topic: HP2551 Issues

[Boomerang]

HP2551 - got up at 5:30 hours and discovered the outside temperature with the blue ring showing - minus 8. The actual temperature was 5.1 on the plus side. For no reason I can tell, it dropped suddenly at 5:15 hours. I unplugged the Console from the power supply and when it restarted, it reverted back to the correct readings. I did delete this reading in the MIN/MAX on the Display Console.

Appears I'm not the only one who has experienced this issue.

Curious if other HP2551 owners have had this problem and if Ecowitt has any solution.

[galfert]

What kind of batteries are you using?

[Mandrake]

I cannot say I have seen this issue.
I would suggest that you contact Lucy and the team can have a look at your Ecowitt.net data and see if they can spot anything obvious.
support@ecowitt.com
They very much care about their products and I am sure they will be keen to help you work out why you had an errant reading

[sky_watcher]

HP2551 - got up at 5:30 hours and discovered the outside temperature with the blue ring showing - minus 8. The actual temperature was 5.1 on the plus side. For no reason I can tell, it dropped suddenly at 5:15 hours. I unplugged the Console from the power supply and when it restarted, it reverted back to the correct readings. I did delete this reading in the MIN/MAX on the Display Console.

Appears I'm not the only one who has experienced this issue.

Curious if other HP2551 owners have had this problem and if Ecowitt has any solution.

I have a HP2550, which I believe is similar. On two occasions I have had the outside temperature jump to a clearly erronously reading (air temp about 45C when it was really less than 20C). Other readings from the tri-arm sensor were not affected that I could perceive. I have not seen the internal temp sensor, the three additional temp/humidity sensors or the two ground moisture sensors do this.

Both times, I was able to get the reading back to match my other outside thermometer by using the "Re-Register Transmitter Outdoor" function (no console power reset). By coincidence, I was looking at the display when it happened, so the anomalies only lasted a couple of minutes while I did the reset. Looking back through my database, I couldn't find any other instances of big temperature jumps like that, nor did I see anything unusual when I compared my readings to the local airport.

I wondered whether there was some device in the area that it locked into. However, I don't know enough about how the RF communication system works to know whether that is plausible.

[Mandrake]

It seems unlikely that you are picking up a different sensor from another household but not impossible and you should definitely check the sensor ID/Setup page on your HP2550 console.
The data is digital and this makes it hard to corrupt but not impossible.
The other possibility is a little software bug that creeps in now and then.
If its always External temp then that's most suspicious from a bug point of view.
I am lucky in that I also have 2 Gw1000's reading my data and CumulusMX logging on a Pi one of these so I should be able to spot an error like this.

[mcrossley]

I have had one user report seeing a few spikes on his outside temperature, it jumped from around 19C to 60C (a suspiciously round number) then back again. I have asked him to enable data logging so I can see exactly what is being sent from the GW1000. Still waiting for the results...

[Boomerang]

What kind of batteries are you using?

I am using Energizer Ultimate Lithium batteries that were brand new when placed into the HP2551 unit.  Of interest, I have noted that the battery strength displayed on the outside unit can jump around - one or two bars - from full strength whereas the inside Indoor temp/humidity sensor is always at full strength.

[Jackpots]

My HP2551 has experienced similar issues this year. The area has reached >41C and >80km/h wind the day before. Then it has lost power for an hour.

I ended up restarting the console to fix it. (assuming the console has lost signals)

[galfert]

Seems to me like the sensor has reset and starts broadcasting on a new ID. When a sensor first starts it randomly chooses an ID. The console then locks into that ID forever (unless the console itself restarts or you manually do a sensor re-register at the console). So when the sensor resets it basically drops out from the console. There could be a bug in the console on sensor dropout that causes the erroneous data. Or perhaps this is by design that when the console experiences sensor drop out that the data goes to either the highest or lowest value possible as an indicator that the sensor has failed or has reset.

Let's take the view point of an engineer designing the station. What should the console do if the sensor experiences a reset or total failure? For example in case of a dead battery or out of range?

Some of my ideas, and I'm just listing all these out as possibilities and not because they are all good ideas.
- The console could continue to show the last value forever (bad idea)
- The console could show the max possible value as an indicator
- The console could show the minimum value as an indicator

There is no other option to display. I suppose it could display an error message, but that would be okay for the console itself. How would that translate to data systems that expect data from a given range? Software is designed to read each sensor as a value. There is no value for error... It doesn't exist. The data protocol is simply a hexadecimal value from 00 to FF. Sure the error could be representative as FF or 00 which would be wildly out of range but the software then too would need to be programed to save null value into database instead of 00 or FF and their representative values. It isn't really 00 through FF because of signed bits, so I'm just oversimplifying to make a point. This is all just computer logic programing at its most basic level. It is what we have to work with. It is up to software to represent data in a meaningful way.

What I think would be a sensible approach is for the console to attempt automatic re-register after a few minutes to see if the sensor automatically came back using a different ID. I don't think the console currently does this. Hence the need to restart the console or do a manual re-register.

This definitely is one to reach out to Ecowitt about.

Bottom line is that the sensor is failing. If the batteries are good Lithium ones, then the sensor may be a defective one. Which means that all the logic programming I discussed is not that critical for a well performing system.

[galfert]

Simpler explanation... The erroneous value could just be the console's response to a lost sensor. Meaning it isn't that the sensor sent out that extreme value, but rather it is the console's response to showing that the sensor was lost.

[sky_watcher]

Simpler explanation... The erroneous value could just be the console's response to a lost sensor. Meaning it isn't that the sensor sent out that extreme value, but rather it is the console's response to showing that the sensor was lost.

The erroneous readings I've seen are within the normal range of readings at the weather station. That is, the around 45C temperature I have seen in winter are not uncommon during the summer with the hottest local temperature being 47.7 °C. I would expect that if the console sent out an extreme value, it would be higher than 60C, its rated maximum temperature. More likely, I suspect, it would send out "--" which I have seen on the display when a sensor battery failed, but before it stopped showing anything for it.

[galfert]

Dash dash -- is not a numerical value. To display - - the console will need to interpret some value as equalling null and thus display - -. Therefore - - is a software processing result and not a sensor sent value. I've read the API documentation, and I've help develop the driver in various software. The only thing a sensor can send is a value from 00 to FF in hexadecimal and - - is not part of the union set.  To display - - that would need to be some predetermined value from 00 to FF to then be interpreted and then have the display show - -. But as far as data sent to other software it would retain that null value.....which in all likelihood is 60°C in its signed 2 byte form.

[Boomerang]

 [ You are not allowed to view attachments ]

So this is the setup of the sensors from Ecowitt engineers that should resolved our issue - at least I hope.

[galfert]

What is your Ecowitt.net station ID?

[Boomerang]

https://www.ecowitt.net/home/index?id=15523

I don't own or use a cell phone so viewing is primarily off both desktop computer and the Console.

[galfert]

Make sure that you have updated the HP2551 display console to the latest firmware. There are 2 firmware types that need to be updated. The process is different for each firmware type.

• WiFi Firmware - This one is simple. But it does require a smartphone. You run the WS View app and it automatically will find the console on the network and upgrade it. You can borrow a smartphone from a friend or family since you say that you don't have one. But maybe you have a tablet ...Android tablet or Apple iPad? That would work also.
• Revision Firmware - This requires a microSD card. These are really cheap now. You only need like a $10 card. 8 GB is common size. They need to say that they are SDHC type. Then you download the Revision firmware to the SD card using a computer. Then you insert the SD card on the display console and power cycle it. It should automatically then upgrade. You can find the latest Revision firmware on this support page under the Manual & Software section.
  

[Boomerang]

Thanks for your reply.

I do have a SD Micro Card in the Console and have updated the Firmware to the latest release HP2551 V1.6.0 - BIN file.  That went smoothly even if I did order the incorrect SD Card at first before the unit ever arrived from Amazon.  I reordered the Micro version of the card and problem solved.

As for an upgrade on the WiFi firmware, we do have a Samsung S3 Tablet however not quite sure how you accomplish the firmware upgrade with a Tablet.  Every one has a Smartphone these days and that is the images you always see.

Curious, when they are doing programing code, what language are they using?  I assume it is C or C# or even Java.  Better not ask Ecowitt, they might think I'm a spy.

[galfert]

Your Samsung S3 tablet should work. Just go to the Google Play Store app and search for and install WS View app.
https://play.google.com/store/apps/details?id=com.ost.wsview

Then once you open the WS View app it will automatically find the HP2551 console on your network and it will automatically prompt you to update the firmware in the app. It is pretty straight forward as it just pops up. If it doesn't automatically pop up then there is a Firmware Upgrade button in the WS View app.

They code in C or C# as I've seen snippets of source code to help fix features and bugs.

[sky_watcher]

Dash dash -- is not a numerical value. To display - - the console will need to interpret some value as equalling null and thus display - -. Therefore - - is a software processing result and not a sensor sent value. I've read the API documentation, and I've help develop the driver in various software. The only thing a sensor can send is a value from 00 to FF in hexadecimal and - - is not part of the union set.  To display - - that would need to be some predetermined value from 00 to FF to then be interpreted and then have the display show - -. But as far as data sent to other software it would retain that null value.....which in all likelihood is 60°C in its signed 2 byte form.

I didn't get 60C. The false readings I got on two occasions were in the 40C range for a few minutes until I resynced the outside sensor. This doesn't seem to support your proposition.

The question (that I don't know the answer to) is whether the console actually controls the sensors, or just intercepts what is transmitted. If it does send commands, then one could assume that resyncing the outside sensors from the console may reset malfunctioning remote sensor. If it only reads the transmissions, then it seems ultra-coincidental that the sensor resets at exactly the time I resynced the console.

Does the console transmit commands to the sensors to reset them?

[galfert]

The console does not sends commands to the sensor. It is a one way radio broadcast from the sensor. Each console model could be programmed to display 60°C or 40°C and it could change depending on firmware revision or model.

[sky_watcher]

The console does not sends commands to the sensor. It is a one way radio broadcast from the sensor. Each console model could be programmed to display 60°C or 40°C and it could change depending on firmware revision or model.

It seems exceptionally unlikely that the reading designating an error would ever have been 40C - that is a temperature that we expect every summer, as do many areas of the world.

Since the sensor does not receive commands, it is unlikely that the sensor is totally the issue, since as soon as I do a resync, the reading returns to normal. The sensor cannot know when I resync, so the chance the sensor always resets to normal at exactly the same time of the resync is vanishingly small.

[galfert]

When the sensor resets itself (same as when batteries are changed out) it starts transmission on a new random ID. At that point the console has lost the sensor that it originally locked into. Yes the very same sensor may now be operational but the console isn't looking for the sensor with its new random ID. The console is still locked onto the original prior ID of the sensor. Therefore whenever you resync the console by either power cycle or by going into the sensor configuration and manually re-register, then the console looks for a new sensor ID to lock onto.

I'm not debating the 40°C as a valid error code indicator. The 40°C value could just be a default value for the sensor to send if it begins to malfunction and then resets. It could be deliberately programmed in the sensor or it could just be an erroneous malfunctioning value.

[sky_watcher]

I'm not debating the 40°C as a valid error code indicator. The 40°C value could just be a default value for the sensor to send if it begins to malfunction and then resets. It could be deliberately programmed in the sensor or it could just be an erroneous malfunctioning value.

No problem. I obviously misunderstood what you were meant when you said "Each console model could be programmed to display 60°C or 40°C and it could change depending on firmware revision or model."

[FreewindRider]

I have also experienced similar issues with my HP1000SE, which is Froggit’s version of HP2551. It has happened quite many times, sometimes it is showing extremely warm temperatures, sometimes extremely cold and sometimes dashes. It always lasts for about an hour until it resets itself and returns to normal readings. It can also be reset by restarting the console. It is only the temperature and humidity that is affected, all other readings are normal. Sometimes it works fine for 2-3 weeks and sometimes it happens again after a couple of days.

I have a DP1500 (=GW1000) connected to the same sensor array and that has always been reporting correct temperatures when the HP1000SE has shown erroneous values, so it seems like the problem is withing the console and not the sensor array.

I have contacted Froggit once, but haven’t got any useful reply, just some standard text explaining what batteries should be used, possible RFI issues etc.

[galfert]

Well can anyone yet confirm that the problem is still there after having updated both firmwares (Revision firmware and WiFi Firmware)?