local access to tags- no internet?

[russel...@gmail.com]

Greetings,

Is there a way to access the tags locally, via a program in Windows?   I know how popular "the cloud" is these days, but if I'm reading a sensor that's 20 ft away, it seems silly to have the data go up to some distant server, then back to my computer.  I already have remote access to my computer, so I would still have access to the data in the rare event I would need that. 

Thanks,
Rusty

[Zhiheng Cao]

Cloud recording the temperature/humidity/motion data allows you to access the data any time, any where. Also it allows you to log the data even if your PC is powered off or not available. 

--
You received this message because you are subscribed to the Google Groups "Wireless Sensor Tags" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wireless-sensor-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[russel...@gmail.com]

Thanks for the quick reply.   You didn't answer the question directly, but can I assume from your response that the answer to the question is NO, there will not be a way to access the tags locally from Windows?  

Cheers,
Rusty

To unsubscribe from this group and stop receiving emails from it, send an email to wireless-sensor-tags+unsub...@googlegroups.com.

[Michael West]

No, there’s no way to access the tags unless you flash a custom firmware on the tag manager.

 

There’s nothing silly about uploading data and downloading data from a server. Because of this you don’t need to worry about the difference between when you’re local and when you’re not, the service works the same.

To unsubscribe from this group and stop receiving emails from it, send an email to wireless-sensor-...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

 

--

You received this message because you are subscribed to the Google Groups "Wireless Sensor Tags" group.

To unsubscribe from this group and stop receiving emails from it, send an email to wireless-sensor-...@googlegroups.com.

[af9...@gmail.com]

I'm with Rusty on this.  I think the whole cloud approach to controls is a step backwards.  I have four cloud control systems including WEMOs, Wireless Tags, Garage Door and Heat Pump system.  My local network is MUCH more reliable and about 100 times faster than going to and from the cloud.  Case in point: after finally getting a Kumo app to run (server was down the first day I tried), it ran well for just one day before the cloud server went down again.  I had to reload and restart everything.  There should be auto restarting from a server failure.  WEMO had similar problems when they were first introduced.  I am so thankful that all my network video cameras are on Blue Iris which provides a cloud free remote viewing and control.  It is a shame that more control systems are not like Blue Iris.

Mike 

[Michael West]

The main problem with that is, for every person that’s inconvenienced by a server problem (I agree Kumoapps should restart), there will be dozens of other inexperienced people who can’t get local connections to work. Their own computer will restart just like that server, or their network has a weird topography. Wireless and wired not bridged correctly? Local firewalls? They simply doesn’t know what local IP to use?

 

The most common feature in SOHO networks is internet. The device and client both know how to talk to “mytaglist.com”, and so they use that. That’s “the cloud” for home automation, and it’s painless. I never have to think about whether my tags are working. Speed is not a problem for WSTs because the data is very small. Latency isn’t a problem because your ping to the server is probably <200ms. Reliability is rarely a problem, because for most people their internet and LAN are stable, and the only time their internet is out is when their power is out.

 

If you require the reliability and speed of LAN at all times, you’d be better off hooking up RPi’s or other systems. WSTs are made for the rest of us.

 

From: wireless-s...@googlegroups.com [mailto:wireless-s...@googlegroups.com] On Behalf Of af9...@gmail.com
Sent: Saturday, December 20, 2014 4:43 PM
To: wireless-s...@googlegroups.com
Cc: russel...@gmail.com
Subject: Re: local access to tags- no internet?

 

 

I'm with Rusty on this.  I think the whole cloud approach to controls is a step backwards.  I have four cloud control systems including WEMOs, Wireless Tags, Garage Door and Heat Pump system.  My local network is MUCH more reliable and about 100 times faster than going to and from the cloud.  Case in point: after finally getting a Kumo app to run (server was down the first day I tried), it ran well for just one day before the cloud server went down again.  I had to reload and restart everything.  There should be auto restarting from a server failure.  WEMO had similar problems when they were first introduced.  I am so thankful that all my network video cameras are on Blue Iris which provides a cloud free remote viewing and control.  It is a shame that more control systems are not like Blue Iris.

Mike 

--

[Alex Kilpatrick]

It would be nice if they gave us an option.  Since it looks like they are just selling the hardware, they could open-source the software.  That way you could run it on the cloud if you want, or from a home server it you prefer.

To unsubscribe from this group and stop receiving emails from it, send an email to wireless-sensor-tags+unsub...@googlegroups.com.

[Zhiheng Cao]

No we are not just selling the hardware. The software is a big part making the product what it is. It's like MacBook vs OSX relationship. 

To unsubscribe from this group and stop receiving emails from it, send an email to wireless-sensor-...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Sent from MetroMail

[Ken Woods]

It's also about you mining bitcoins, but you'll deny that.

On Monday, December 22, 2014 3:43:39 PM UTC-9, mytaglist.com support wrote:

No we are not just selling the hardware. The software is a big part making the product what it is. It's like MacBook vs OSX relationship. 

On Sunday, December 21, 2014, Alex Kilpatrick <alex.ki...@gmail.com> wrote:

It would be nice if they gave us an option.  Since it looks like they are just selling the hardware, they could open-source the software.  That way you could run it on the cloud if you want, or from a home server it you prefer.

On Saturday, December 20, 2014 8:49:32 PM UTC-6, Michael West wrote:

The main problem with that is, for every person that’s inconvenienced by a server problem (I agree Kumoapps should restart), there will be dozens of other inexperienced people who can’t get local connections to work. Their own computer will restart just like that server, or their network has a weird topography. Wireless and wired not bridged correctly? Local firewalls? They simply doesn’t know what local IP to use?

 

The most common feature in SOHO networks is internet. The device and client both know how to talk to “mytaglist.com”, and so they use that. That’s “the cloud” for home automation, and it’s painless. I never have to think about whether my tags are working. Speed is not a problem for WSTs because the data is very small. Latency isn’t a problem because your ping to the server is probably <200ms. Reliability is rarely a problem, because for most people their internet and LAN are stable, and the only time their internet is out is when their power is out.

 

If you require the reliability and speed of LAN at all times, you’d be better off hooking up RPi’s or other systems. WSTs are made for the rest of us.

 

From: wireless-s...@googlegroups.com [mailto:wireless-s...@googlegroups.com] On Behalf Of af9...@gmail.com
Sent: Saturday, December 20, 2014 4:43 PM
To: wireless-s...@googlegroups.com
Cc: russel...@gmail.com
Subject: Re: local access to tags- no internet?

 

 

I'm with Rusty on this.  I think the whole cloud approach to controls is a step backwards.  I have four cloud control systems including WEMOs, Wireless Tags, Garage Door and Heat Pump system.  My local network is MUCH more reliable and about 100 times faster than going to and from the cloud.  Case in point: after finally getting a Kumo app to run (server was down the first day I tried), it ran well for just one day before the cloud server went down again.  I had to reload and restart everything.  There should be auto restarting from a server failure.  WEMO had similar problems when they were first introduced.  I am so thankful that all my network video cameras are on Blue Iris which provides a cloud free remote viewing and control.  It is a shame that more control systems are not like Blue Iris.

Mike 

--
You received this message because you are subscribed to the Google Groups "Wireless Sensor Tags" group.

To unsubscribe from this group and stop receiving emails from it, send an email to wireless-sensor-tags+unsubscrib...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Wireless Sensor Tags" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wireless-sensor-tags+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Sent from MetroMail

[Buxton252]

The lack of local access is going to send this product to a quick grave.  Cheap wi-fi sensors:  great idea.  Mandatory cloud service: the model might appeal to a homeowner with just a router (what's that??) looking for a turnkey, but a quick look at the messages on this board will reveal that the supposed target demographic is not the group that is buying the product.

As well, the bigger players are going to jump into this space, as well as cheap Chinese knockoffs, and their biz model is not going to hinge on running servers.  It's too bad cause I'd like to see a small entrepreneur break out in this space, but it's not going to be this product.

[Michael West]

Judging by the popularity of services like IFTTT, and products like WeMo and Philips Hue, there is a good market for a product where it just connects to the internet with limited or no local access. The people on this group are just a little more advanced, heh. Most of us are enthusiasts.

 

How would local access even work? The tag manager doesn’t have any storage except for its serial number. It can hold events in RAM until they’re sent. Would there be a much more expensive tag manager with storage? How would you use it? Set it up with an IP, access it on a web page, and see temperatures? It would lose the ability to send push notifications, keeping multiple tag managers in sync would be really difficult, setup would be complicated. What would be the benefit?

 

I really am trying to understand how a change like this would be beneficial, or how it would even work... They’ve made changes (Sensor Tag Pros) for certain business needs, but this just doesn’t make sense to me.

 

From: wireless-s...@googlegroups.com [mailto:wireless-s...@googlegroups.com] On Behalf Of Buxton252
Sent: Tuesday, February 10, 2015 10:34 PM
To: wireless-s...@googlegroups.com
Subject: Re: local access to tags- no internet?

 

The lack of local access is going to send this product to a quick grave.  Cheap wi-fi sensors:  great idea.  Mandatory cloud service: the model might appeal to a homeowner with just a router (what's that??) looking for a turnkey, but a quick look at the messages on this board will reveal that the supposed target demographic is not the group that is buying the product.

--
You received this message because you are subscribed to the Google Groups "Wireless Sensor Tags" group.

To unsubscribe from this group and stop receiving emails from it, send an email to wireless-sensor-...@googlegroups.com.

[DaveGadgeteer]

Michael West has got it right.

This system has made a design choice to rely on a central server, which simplifies the support and reduces costs by an enormous factor. I suspect this is much more important to their success than any technical details about the sensors or their design. It makes possible the extremely powerful and flexible customized software that we each can write using their Kumostat server. That's a BIG deal, in my estimation.

Obviously all the communication between the tag manager and the internet is done using IP packets, so if someone wants to deduce the protocols in order to access the tags locally, they can intercept the packets and do it that way. But for the tag company to change to such a system would result in an enormously larger support problem--from one type of configuration to a large number of ill-defined configurations to support. If they become extremely successful, they could decide to expand in that direction if they see sufficient market for it, but I'd be surprised.

Similarly, some people want POE tag managers. I'd love one also, but I'm more interested in this tiny company surviving so it can continue to fill my orders. I'll live with a slightly kludgy POE add-on until the day comes that they can afford to design and support a second version of the tag manager (not everyone wants POE).

If we're willing to pay sufficiently higher prices to make these changes profitable, they could happen. But I'd rather have the capability we're getting now, at the current prices. This tiny company has to struggle with creating new products, expanding their infrastructure to support their growing customer base and sales (I hope), and deal with patent attacks if they start to look profitable.

(Every real product violates multiple patents that can be used to extort or suppress, even though most of those patents should never have been granted. The only way to survive is to form alliances with the big patent pools, or be bought by someone who has such alliances and a big visible legal team with lots of resources, or to remain too unprofitable to be attractive to attackers. I'm guessing this latter is their current (default) strategy.

I really wish them well, and admire what they've achieved so efficiently. I think the complainers don't really have the big picture yet. (I do have complaints of my own, but I'm keeping them in perspective and giving the company some breathing room. Support has been prompt when the system is at fault, but clearly has to triage to avoid wasting time on unsolvable "problems" or on unproductive requests to just do everything differently--some customers should just ask for their money back and then go buy something they consider more satisfactory. I do think it would help to have a user-editable Wiki that we could all work on to improve explanations and make the documentation easier to sort out. There's a lot of info hidden in this group and on the websites, but it's not easy to find when you need it.)

Dave

[Francesco Verga]

A part from economic strategy, I don't care about cloud or local service. I care about a working service.

I wrote a kumo app to load sensor data into local mysql server linked with the house heating system.

This night (1:37 CET) the cloud system went down and the kumo app stopped running and my system didn't get any data (at this time I can not even log in into the system). 

So this morning the heating system didn't start. And this is my problem.

With local access this wouldn't have happend or at least it would have been my personal fault (that I could correct).

F.

[wiigor zweeffan]

I have exactly the same problem, I am using these sensors to control my dehumidification / aircondition system as well as inputs for my security system to drive security cams. When motion is detected a photo is taken. But often this is too late. Also my neighbour wants to use this system to help manage a property without internet connection. We would like to have a way to access the sensors data locally.  For example to get the values via a JSON or Rest Api or a very simple website with only a table with values. We would even we willing to pay more for the control box if it would include offline readout options.

[Ron E]

I fully agree that relying on the Internet is not a viable way to build out automation services.  I have seen the backend go down on countless occasions over the past couple of weeks making the tags essentially worthless and preventing the use of them in normal home automation scenarios.  It is quite unfortunate because many of the design patterns and thought which went into building these economical sensor is fantastic.  If the platform would be opened up to us (software engineers), we could extend and improve on the great work which has already been done.  Although, as already mentioned, we could capture the network packets and reverse engineer the information, if it is not a public supported API, it is a waste of time.  I have to expect at some point in time, Michael will realize that, for localized automation, you cannot rely on the internet, unless the sensor are only going to be relegated to long-term historical collection of temperature and humidity.

BTW:  Willing to help design and engineer a solution!

[Justin Erickson]

The only reason I havent pulled the trigger on this product is that in relies on the "cloud" service that a company controls. If the company tanks in 6 months, i paid a few hundred dollars for something that no longer works with out their cloud.

To make this work, they simply provide the server software or "cloud software" to us enthusiasts that would like to host it ourselves. Simple.

I worry about the day, Wemo, hue, and nest decide to stop supporting old devices on their "cloud" to force us all to buy the new models. Or worse, the company closes and we have no more smart home.

To unsubscribe from this group and stop receiving emails from it, send an email to wireless-sensor-tags+unsub...@googlegroups.com.

[Ron E]

Agreed.  I have spent quite a bit on Philips Hue which has an internal bridge for local IP communications.  They have implemented a fully, local RESTFul API which works great.  They also integrate with a backend server for proxying to your local hub when outside your local Wireless area

I have invested in about 15 sensor to test out the hardware.  The sensors are relatively solid for their price.  Unfortunately, the KumoApp coding and back-end servers are not.  Conceptually, using a JavaScript interpreter is once again a good design choice; however, it has not been fully implemented making writing and debugging very difficult.  I have spent the last hour on trying to debug something as simple as:

var hue_bridge=<%Hue bridge IP address_H%>;

var hue_user=<%Hue username%>;

var hue_lampids=<%Hue lamp IDs (separate by ,)%>;

var pirEntrySensor=<#PIRSensor_[72]_2#>;

var pirExitSensor=<#PIRSensor_[72]_3#>;

pirEntrySensor.detected = function(sensor)

{

    KumoApp.Log(sensor.name + " motion detected" ); 

}

pirExitSensor.detected = function(sensor)

{

    KumoApp.Log(sensor.name + " motion detected" );   

}

 

which is giving the error:

(SyntaxError: Unexpected token in '<' expression.)

followed by the Jurassic compiler giving a stack trace to  

 

endTokens) in c:\z560_backup\jurassic_0336599937d3\Jurassic\Compiler\Parser\Parser.cs:line 1627 at Jurassic.Compiler.Parser.ParseVar() in c:\z560_backup\jurassic_0336599937d3\Jurassic\Compiler\Parser\Parser.cs:line 483 at Jurassic.Compiler.Parser.ParseStatementNoNewContext() in c:\z560_backup\jurassic_0336599937d3\Jurassic\Compiler\Parser\Parser.cs:line 384 at Jurassic.Compiler.Parser.ParseStatement() in c:\z560_backup\jurassic_0336599937d3\Jurassic\Compiler\Parser\Parser.cs:line 369 at Jurassic.Compiler.Parser.Parse() in c:\z560_backup\jurassic_0336599937d3\Jurassic\Compiler\Parser\Parser.cs:line 353 at Jurassic.Compiler.GlobalMethodGenerator.Parse() in c:\z560_backup\jurassic_0336599937d3\Jurassic\Compiler\MethodGenerator\GlobalMethodGenerator.cs:line 56 at Jurassic.ScriptEngine.Execute(ScriptSource source) in c:\z560_backup\jurassic_0336599937d3\Jurassic\Core\ScriptEngine.cs:line 647 at MyTagList.KumoAppEngine.KumoAppService.Sandbox.ScriptEngineWrapper.Execute(Script script, Boolean log) in c:\z560_backup\MyTagList\KumoApp\KumoAppService.cs:line 310

Jurassic.JavaScriptException: SyntaxError: Unexpected token '<' in expression. at Jurassic.Compiler.Parser.ParseExpression(Token[] endTokens) in c:\z560_backup\jurassic_0336599937d3\Jurassic\Compiler\Parser\Parser.cs:line 1627 at Jurassic.Compiler.Parser.ParseVar() in c:\z560_backup\jurassic_0336599937d3\Jurassic\Compiler\Parser\Parser.cs:line 483 at Jurassic.Compiler.Parser.ParseStatementNoNewContext() in c:\z560_backup\jurassic_0336599937d3\Jurassic\Compiler\Parser\Parser.cs:line 384 at Jurassic.Compiler.Parser.ParseStatement() in c:\z560_backup\jurassic_0336599937d3\Jurassic\Compiler\Parser\Parser.cs:line 369 at Jurassic.Compiler.Parser.Parse() in c:\z560_backup\jurassic_0336599937d3\Jurassic\Compiler\Parser\Parser.cs:line 353 at Jurassic.Compiler.GlobalMethodGenerator.Parse() in c:\z560_backup\jurassic_0336599937d3\Jurassic\Compiler\MethodGenerator\GlobalMethodGenerator.cs:line 56 at Jurassic.ScriptEngine.Execute(ScriptSource source) in c:\z560_backup\jurassic_0336599937d3\Jurassic\Core\ScriptEngine.cs:line 647 at MyTagList.KumoAppEngine.KumoAppService.Sandbox.ScriptEngineWrapper.Execute(Script script, Boolean log) in c:\z560_backup\MyTagList\KumoApp\KumoAppService.cs:line 310

[Michael West]

Hey Ron,

 

The error in your script comes from the first line: var hue_bridge=<%Hue bridge IP address_H%>;

There’s an _N option, but no _H, that’s what it’s getting hung up on.

 

I continue to recommend that if you have the skills in the first place to implement something locally like you are suggesting, then don’t use KumoApp at all. Use the HTTP notifications and send them to your own server and do processing on them. Heck, send them back to your house to your own server. I use Google Apps Script because it provides a full-fledged Javascript environment just like KumoApps but with Google-level reliability and features, and I have never had downtime. That’s what the service was originally designed for.

 

KumoApps aren’t reliable yet and I wouldn’t use them if they’re doing something relatively important like controlling the heat to your home. Hopefully the apps will improve because it’s a great idea, it just has some rough edges.

 

--

Michael West

https://mwe.st

To unsubscribe from this group and stop receiving emails from it, send an email to wireless-sensor-...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Wireless Sensor Tags" group.

To unsubscribe from this group and stop receiving emails from it, send an email to wireless-sensor-...@googlegroups.com.

[Ron E]

Michael,

Thanks for looking at the script but, I don't believe that's the problem.  

var hue_bridge=<%Hue bridge IP address_H%>;

 

Is prompting for the IP Address of the bridge in the Configure section and that seems to work fine. Even after removing it, I get the same error but with that said, and with what you said about KumoApps, I guess it's time to give up on KumoApps for now.  I wanted to try something different since, its been  C/C++/C#  for the past 35 years!  I'll take a look at Google App Script but, If I recall, I saw some libraries in .NET....

Thanks,

Ron

To unsubscribe from this group and stop receiving emails from it, send an email to wireless-sensor-tags+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Wireless Sensor Tags" group.

To unsubscribe from this group and stop receiving emails from it, send an email to wireless-sensor-tags+unsub...@googlegroups.com.

[Michael West]

Hey Ron,

 

Occam’s razor… There’s another line with the same error. I just didn’t notice it because I only tested the first line.

 

If you read this page: http://wirelesstag.net/kumoapp/17/tags-kumosensors-kumostats

The “_1 or N” is either or, it doesn’t mean you can specify the number of tags. So you should be using:

 

var pirEntrySensor=<#PIRSensor_[72]_N#>;

var pirExitSensor=<#PIRSensor_[72]_N#>;

 

Documentation could be better in that respect. Do look at the example code, it’ll help you a lot.

To unsubscribe from this group and stop receiving emails from it, send an email to wireless-sensor-...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Wireless Sensor Tags" group.

To unsubscribe from this group and stop receiving emails from it, send an email to wireless-sensor-...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Wireless Sensor Tags" group.

To unsubscribe from this group and stop receiving emails from it, send an email to wireless-sensor-...@googlegroups.com.

[Zhiheng Cao]

Hi Ron, 

Like Michael West already pointed out, this error is caused by 

var pirEntrySensor=<#PIRSensor_[72]_2#>;

var pirExitSensor=<#PIRSensor_[72]_3#>;

It should be 

var pirEntrySensor=<#PIRSensor_[72]_1#>;

var pirExitSensor=<#PIRSensor_[72]_1#>;

 

Anything with <#...._[72]_1#> is replace with the actual tag object, and anything with <#...._[72]_N#> is replace with Javascript array [tag1, tag2,... ] which means you need to use forEach(). 

To unsubscribe from this group and stop receiving emails from it, send an email to wireless-sensor-...@googlegroups.com.

[Francesco Verga]

I partially solved the solution using the URL call function (with a php/mysql backend) instead of kumoapp. It's working for temp & RH but not for movement detection. Maybe I have to double check but I can't see the call when movement is detected.

Notably from Apache access log I see that the call comes from the tag manager IP and not the web. I have to try to close the internet connection and see what happens.

F.

[wiigor zweeffan]

Hi Francesco ,

Do you mean you have a way to access the sensor readout locally without internet? If so could you elaborate more on how you did it?

[Michael West]

Hey Wiigor,

 

For events you can use the custom URL calling for the tag manager call a local IP:

 

You could put for example http://192.168.0.10/tag8 in that field as long as you check the private IP box. You have to run a server locally of course.

However you can’t use an API or anything like that to ask the tag manager what a tag’s temperature is, this is receive-only. Note that for the temperature/moisture events I think it only triggers when it first crosses the threshold.

 

This isn’t a replacement for internet access. When the tag manager restarts it has to load all its settings from the web. If you have say a property that’s remote and doesn’t have internet access, this won’t really work. In that case I would recommend a small travel router and a cheap prepaid 3G USB stick.

 

--

Michael West

https://mwe.st

 

From: wireless-s...@googlegroups.com [mailto:wireless-s...@googlegroups.com] On Behalf Of wiigor zweeffan
Sent: Tuesday, February 24, 2015 4:05 PM
To: wireless-s...@googlegroups.com
Subject: Re: local access to tags- no internet?

 

Hi Francesco ,

--

[Francesco Verga]

Hi Wigor,

I mean that in Apache log I see:

192.168.100.180 - - [22/Feb/2015:13:04:17 +0100] "GET /mybackendxxxy.php?tag=Bimbi&movimento=0 HTTP/1.1" 200 203 "-" "-"

and 192.168.100.180 is the local IP of tag manager. It means that the url request comes from the tag manager and not a cloud server.

I still have to check what happens if I cut down the internet connection.

F.V.

[wiigor zweeffan]

Hi Michael,

Thanks for your explanation.

Could it be possible to just make a DNS server at home and route the requests of the tag manager to that server. And then send some config file? (the one that he tries to get from the internet)

 Anyways Maybe we will have to go with the 3G stick solution. Any idea of the amount of data the tag manager will send and receive from the internet per month for about 15-20 sensors with high update rates?

Thanks,

Wiigor