Sending UDP or TCP packets to an address inside the local area network?

I have my imp equipped with a 1-wire temp sensor and it works great. What I would like to do is for the imp to report the temperature every hour to a Raspberry pi on the local network to keep a log of the temperature. How do I accomplish this?

Does the outside network always need to be involved? That would be a real bummer, because the internet connection is sometimes a bit flaky here. I would need a way for the imp device to send a simple message inside the local area network. Please don’t tell me the imp cannot do this…!

aw sh*t

Found this comment by Hugo in the feature request section: “…we will never provide a wifi module that doesn’t use our service, because we are a platform company that happens to provide hardware, not a hardware platform that happens to want to sell you a cloud service on the side”

You know what… I thought I was buying a cool little piece of hardware that can communicate through Wifi and that I could use for anything I wanted. Where exactly was this information that you are forcing feeding your cloud service on me in the showcase videos? Having most of the code as open source but then having such restrictions is not exactly being up-front about it. Having the hardware to be able to do something but restricting the functionality because of whatever bullsht reason is not how any business should operate. You have wasted my time and money and on the behalf of every open source enthusiast and hobbyist… FCK YOU! I want my money back.

Wow, that’s a lot of hostility. Absolutely ALL the dev guides, online documentation, and promotional material show the imp connecting to our cloud service. We have never advertised it as being a local network wifi module. The APIs are publicly documented and you’ll note that there aren’t any for local network access.

I’m sorry you appear to not value a well supported, solid, reliable, secure internet connectivity platform - our customers, however, do, and those are the people the company was founded to satisfy.

The reason we don’t provide local network access is that it’s a security hole - should a device’s application code become compromised, it would allow attacking of devices behind end user’s firewalls, which is not acceptable for our customers. Restricting network access at the VM level prevents this vector from being exploited.

There are plenty of options on the market which give you a processor and a wifi chip and all the rope you desire.

If you want a refund, first try contacting the place you bought it (your IP address appears to be in Finland), but if you have no luck then send me a PM.

@nurminen, there are many open-source enthusiasts and hobbyists using the Electric Imp platform. Most of them took the time to read the documentation, so they knew what they were getting. If you care to re-read your own first post, you’ll understand why. You got an imp equipped with a 1-wire sensor that “works great”. It wouldn’t be so simple without a comprehensive, robust and secure platform.

It never occurred to me that I would be prevented from using such elementary functionality as sending messages where ever I wanted. You should at least let the developer edition imps do what the user wants. I don’t think it is that easy to find a low cost, low power consumption, wifi enabled device.

I guess I mistook the imp for what it was. I think I might still be able to use it with a nasty work around if I put in 10 times the effort… but now it wont even boot up with the batteries even though I’m reading 2.8V on the pins. I think it’s time to cut my losses and move on.

“Developer edition” is just custom laser etching on the first 10k devices made; they’re identical to all others in both hardware and software.

You can, in fact, send messages anywhere you want - anywhere that is generally accessible on the internet (hence: Internet of things and not Lan of things).

You’re unlikely to have a solid 2.8v if the imp isn’t booting; during wifi PA cal pretty much any wifi chip will take >200mA peaks which would cause a brownout. You don’t specify your battery type but alkalines are not good with current peaks (high internal resistance) and a Li-Ion is pretty much totally dead by the time it goes below 3.0v.

Yeah great. For me it is a much more real security concern to have to open up a port for the server in your cloud to be able to log a temperature reading to a machine back inside my lan. I’m behind a wireless internet connection for my project and I don’t even want to know how that would work with a possibly changing IP, or alternatively, storing the readings in the cloud and polling to read them with a non-imp device.

I thought two AAA batteries (~3.0V) would be able to run the imp for a good while, looks like that wasn’t the case.

Thanks for the responses though.

There’s a 2 cell reference design (see https://electricimp.com/docs/hardware/resources/reference-designs/nora/ ) which has the necessary boost supply; this works pretty well with AA’s and should be fine with AAA’s too, but the smaller the cell the more internal resistance.

eg, see the Energizer E92 datasheet: http://data.energizer.com/PDFs/E92.pdf and look at the 250mA discharge graph on page 2, top right; the imp really needs 2.6v, and the cells hit 1.3v each after only 125mAh of capacity has been used (0.5 hours * 250mA) at 21C.

If you used an L92, http://data.energizer.com/PDFs/l92.pdf then you do a lot better. They don’t have the same graph for the L92 but the “discharge profile” one shows it’s essentially all above 1.3v per cell for the entire battery lifetime.

The above is applicable to most wifi devices from an ESP8266 upwards (though, most won’t run down to 2.6v)

nurminen,
You can easily use the Imp with your LAN, just put a proxy between the Imp and the net. You can interpret any LAN pointed response to any Impish signalling (doesn’t make a difference if it’s encrypted, just use patterns). I also agree that your hostility doesn’t really help (any situation).

@jortony you may have limited luck there with reliably inferring meaning from (eg) packet lengths, because we do send chaff packets back and forth over the link to hamper just such types of eavesdropping…