Archived Forum

Never realised smappee was that cheap?!

[Duplicate post deleted. Please read "NEW USERS, PLEASE READ - Posts held for moderation"]

Yes the price of Smappee shocked me too, when discussing with my supervisor.
Is why I opened this post, not as a critic but as awareness so that Open Energy Monitor can hopefully take into account the situation.

Apologies for the dupe post, I had read the New Users, Please Read....

but if nothing comes up saying waiting for moderation, or you are in a queue, your message is important to us, then you will of course get multiple posts.

"if nothing comes up..."

But it does. You didn't see it.

Hapless,

It looks like this:

I'm not sure that message sticks around once the page is reloaded though.

obviously I didn't see the warning, otherwise I wouldn't have posted again!

OK, time to move on, back to Christophe's original point...

Smappee UK price for single phase, solar equipped installation is £179 inc. vat and carriage.

Equivalent OEM is £183.73 inc. vat and carriage

The whole smappee package looks very polished and complete - not tried it but from folk who have they are pleased with how it tracks individual loads/appliances, but again there are issues with smaller loads?

Smappee is a self-learning system that improves accuracy in identifying loads over time. Indeed some glitches like iron being mistaken with stove. It basically gives your overall consumption situation as well as a breakdown of power and duration per device.

However as it is a commercial system, the code on Smappee itself cannot be hacked, only export of results from Smappee server via API. Hence the beauty of Open Energy Monitor, as you can decide what to send to the server as well as the interval.

Open Energy Monitor lately is just giving me unnecessary work, in having to identify bugs in the code and fixing them each time. My point being that if new features will be added to the code, at least test them properly and do not leave half un-functional functions in the code, just put them in a separate file or Github fork so that it is clear that those new features are faulty (I am referring to latest Emoncms release v8.5). 

Just to say that after my thesis, I will create a new fork with all the complaints I have mentioned fixed. And overtime new up-to-date in comparison with other alternatives functions implemented. 

--------
Lastly just a suggestion about the post moderation issue: why not give the moderation power to the topic opening user as well, to give less work to site administrators ?

The whole smappee package looks very polished and complete -

Yes, true, very nicely done.

But as far as I can see from the description it only measures phase currents, not voltage. If that is true it cannot measure consumption very precisely. Correct me please if I am wrong.

Jörg.

But as far as I can see from the description it only measures phase currents, not voltage.

The installation section of the manual doesn't show a mains connected VT, only CTs.

So, unless the power supply for the Ethernet gateway is also the VT, (which may, or may not, be a bad thing) I'd say Jörg is correct.

http://cdn.smappee.com/media/wysiwyg/Manuals/Smappee_IM_UK_Installation_...

http://cdn.smappee.com/media/wysiwyg/Manuals/Smappee_IM_US_Installation_...

Smappee gets its voltage signal from the "wall-wart", not unlike the latest emonTX stuff.  From the two installations I've seen it can measure real power impressively accurately, but the appliance recognition stuff is pretty hit and miss.  Both the owners I know have stopped using that feature, and just use it as a very accurate whole-house power monitor.  I suspect in multi-phase installations it must be doing some sort of guess about the other phases (again like some OEM 3 phases sketches).  And in the US it can only see one leg, so must assume the other is identical in amplitude.

I suspect the appliance recognition will only ever be as good as the amount of effort you're prepared to put it, and it takes an enormous amount of effort so that's why my two buddies have given up on that part.  When you look at a complex load like a dishwasher running for 50 mins. you see why it's problematic.  I think Smappee notes the current signature (i.e. the fundamental and quite a few harmonics) of every event it sees.  So every relay, solenoid, and pump in your dishwasher all appear as unique unknown appliances that you need to identify and group together under dishwasher. 

One of my buddies gave up early, still will hundreds of unidentified "appliances" in his house, while the other was a lot more determined.  But for his efforts, he's now told his dishwasher has come on when he turns his oven on.  I suspect it will improve over time, especially if they can pull off a crowd sourced database of signatures that new users get for free.... but they'll need more determined customers than the two I know.

I had wondered how this would be able to recognize all the many different cycles that say, a washing machine could present and cater for outside influence like changes in time to heat water due to initial water temp variations by season etc and densely filled verses light clothing etc monitoring at a component level accommodates that but what about wear and tear or replacement parts throwing a spanner in the works? I'm not sure I would have the patience, excellent concept I hope it progresses but it is without a doubt quite a different product to OEM.

Paul

Smappee gets its voltage signal from the "wall-wart", not unlike the latest emonTX stuff.

Ok, that is a good information. I could not extract this from their web page.

Do you know how the appliance recognition works in practical terms? Does it always present you a number of 'unknown' loads where you have to tell it which load is which or does it make an 'educated guess' itself?

Jörg. 

It just assigns them sequential numbers as it finds them, and it's up to you to edit "Appliance 85"  into "Garage Door" or whatever, when (if?) you eventually work it out.  It's been a good 9 months since I've played with one, so there's a chance it's improved since then.  I vaguely recall it asked you for a Make/Model of appliances, which made me think they were crowd sourcing a database of signatures.  So maybe they can now (or one day) say... "It looks like you have an LG Fridge Model xxx,  confirm?".

Oh, and it has a training mode too, where you can say "Listen up, I'm about to turn the TV on".  My buddy tried that with his circulation pump over and over, and it refused to see anything... although total power went up by the correct amount when he turned it on.

Nice to see the debate about the difference between OEM and Smappee, as well as the appliance recognition feature of Smappee. 

So as was mentioned Smappee is both powered and measures voltage from the "wall-wart". This is clearly an advantage over emonTX where you need 2 voltage supply inputs if taking voltage measurements. And doing some research shows that powering the Nanode or Arduino base from the shield is not a problem. That would be one major design improvement. 

Secondly appliance recognition is extremely complex, so I do not expect Emoncms to instantly address this feature. However my main point about Emoncms is that the existing functionality can be improved. There are numerous posts about features not behaving as they should and as I can see when myself debugging many half-complete functions. And as mentioned integration with IFTT or working on how to control remote devices is a reasonable objective in the main aim of keeping Open Energy Monitor competitive to other commercial options. 

To summarise, one has to see Emoncms and OEM from a non-technical user perspective as well. 

So as was mentioned Smappee is both powered and measures voltage from the "wall-wart".

I'm no expert on EmonTXs, but I'm pretty sure the latest ones use the AC wall-wart for both V sensing and powering the unit.

Secondly appliance recognition is extremely complex, so I do not expect Emoncms to instantly address this feature.

I think Emoncms would be very challenged to do appliance recognition with the data it typically receives today.. i.e. average power used over the last 10 seconds.  I suspect you'd need some serious DSP horsepower right down at the pointy end where the signal arrives, to extract all the harmonic info.  At least  I think that's how smappee does it. 

I'm no expert on EmonTXs, but I'm pretty sure the latest ones use the AC wall-wart for both V sensing and powering the unit.

Yes the emonTX V3 is as you say, but not the Shield V2 nor the new emonPi. But there is a significant cost difference when selecting the emonTX V3 option.

Either way the emonTX V3 would require a Base unit which would be that second "wall-wart". Not to mention the overall larger space requirements. Using the emonTX Shield effectively tackles this problem. Hence my preference for the emonTX Shield V2 combined with Nanode option.
--------

Secondly appliance recognition is extremely complex, so I do not expect Emoncms to instantly address this feature.

I'm looking into this. Ok but if more DSP horsepower was the effective issue, this can surely be addressed with new hardware. 

Another smappee-like product that does appliance signature recognition:

https://www.indiegogo.com/projects/ecoisme-intelligent-energy-monitoring-system#/story

First prototype built from an Arduino!

Very interesting to read about !
Definitely with a bit of effort, can the same device recognition eventually be integrated into Open Energy Monitor. 

Right now after running into problems with 3-phase measurements, similar to http://openenergymonitor.org/emon/node/10419 , I will have to fix the issue before finishing my thesis.

The eventually can I explore the device recognition functionality. 

Do you guys think it is possible to analyze the patterns of each device with 10s interval monitoring or will it require more high resolution analyzing?

Does these units analyse inside the hardware or on the server?

Both units looks interesting, and this is probably the way to go also for the professional market, as this would reduce the amount of sensors needed to be installed. Alot of events kan be sensed from just logging a few points of temperature and energy/power.

//J

I think 5 second interval would be more appropriate.

Good question about where the analysis is done.
I would go for analysing on the server, as in addition to better hardware you afterall view that resulting data on app/web-interface.
But is important to note that an Arduino alone is not sufficient for these new requirements.

A lot of changes required.
It is just a pity that Open Energy Monitor does not live up to the expectations of Open Source Projects, in the sense that the Open Product is at least as good or better or cheaper than commercial alternative.

As mentioned is some posts above, I really want to fix this gap.
So if you have experience or motivation just message my profile, we can discuss how to tackle the issue.

@christophe_meyers: just came across that thread and your problems with 3 phases...Just to make it short because it has nothing to do with the subject of this topic:

Since I have enabled CT4 (see http://openenergymonitor.org/emon/node/10419) but don't use it, the system looks fine to me. I share some data here http://emoncms.org/daturach. As a base, I loaded the sketch attached by Robert Wall in my original thread (10419).

Hello daturach,

See my comment at http://openenergymonitor.org/emon/node/10419
Seems to require rethinking the voltage array procedure.
Please let me know if it works for you, as my code surely requires more testing and feedback.

Thanks

Christophe

Christophe, both you and I had completely missed the true source of the problem. Use the present sketch on Github, which has been corrected (V3.4 only).

Robert,

Following the comments at http://openenergymonitor.org/emon/node/10419 , I have indeed used the new V3.4 sketch. However the problem is still there, as the values I get using that sketch still are 'ovf' sometimes. Hence my effort in trying to address the issue.

I'm going to have to take this occasion again, to state that this Open Energy Monitor project is not being well managed. For several reasons:
   - when someone publishes new code (like my 3-phase now), at least congratulate their effort. Did you test my code ? No, I suppose. Simply reject whatever you don't appreciate. Open Source is about working together, not a centralized top-down approach as I feel is now (your project is purely commercial to sell your hardware, other Open Source aspects are neglected). You people running the project cannot get all ideas and by encouraging contributions from other people, can the project get better and better. Open Source has some values that really are not being respected.
   - by welcoming contributions (not just your ideas) will the project move forward. As right now Open Energy Monitor is by far behind all other commercial options. I know you people running the project don't take this into account, but again for the sake of an Open Source project with motivated contributors, please wake up. Are you aware of https://www.indiegogo.com/projects/ecoisme-intelligent-energy-monitoring-system#/story ? This project is definitely based on Open Energy Monitor (first prototype at least) and by being open-minded, did they turn it into a viable business model. How many more times will Open Energy Monitor need to be let down like this, before new ideas are welcomed to Open Energy Monitor ?
   - as already stated above, I will make a new Open Energy Monitor project, where ideas and collaboration is welcomed. That is why Open Source is better than commercial, through encouraged collaboration ! Is a pity that I need to go that extent, but what can I do ?

Christophe

I work for one of the most popular integration / building controls / energy management companies in the UK and can also say that the key to progression and uptake is integration.

Being able to integrate the openenergymonitor eco system into existing, already established frameworks such as those used in building energy management etc is important.

I have been playing with openenergymonitor now for only a few days and its great. Therefore we just designed a software module for the worlds most advanced integration platform 'Tridium Niagara AX' that leverages the emoncms API in order to get datapoints into the Niagara Framework which then allows for complex control, analytics and general integration into a building management system.

There is a lot to be said for having a good, simple API... And since emoncms already has one, I feel that it is already geared up to become something big.

Open Source is good for everyone!

I have no intention of taking part in any public discussion about the management of OpenEnergyMonitor.

I'm going to keep my answer short, as my previous unapproved post went into too much detail.

Basically encouraging user contributions and understanding that Open Energy Monitor must integrate with other available systems is key.

That's all I'll say, others can understand from between the lines what I mean.

Interesting read and research here: http://csserver.ucd.ie/~aruzzelli/pubs/Secon10_REAR.pdf