fyi: I’'m currently developing a X-Sense binding to support their low-cost portfolio (https://de.x-sense.com)
Use Cloud API (it seems that there is now way to access the base station via WiFi on the local network based on my research results. Even MQTT gets routed via the cloud and comes in via WebSocket connection)
Support for Homes, Base Stations (SB50 - no others)
Support for standards sensors like smoke, water…
Support for alarm system sensors like window, motion detector incl. the keypad
Some (!) control functions, e.g. mute alarm per device / overall, set arm mode
A Web-UI (X-Sense Manager) to provide some more insights
Let me know if you are interested to support with testing. It already looks good so makes sense to start community testing.
A very good reason to not buy those devices then. We should all know what “cloud only” devices means by now: Free at first, then more and more expensive subscriptions are required, until one day they decide it’s time to force you to buy something new, so they just drop support for the devices you have.
That said, don’t you have enough on your hands already
I know. Neverthess, the devices have a very good price/value, easy to install/handle.
Only the bridge has WiFi, the sensors etc. are connected via their own radio protocol. The base station could be fenced in a VLAN or with client isolation on the WiFi network.
I know, you are still exposing data to the cloud, but like many other openHAB bindings and with limited access to Internet and local network.
Thins are progressing well. Nevertheless, this is low priority and focus is the Shelly binding.
You should start with a pack, this us way cheaper than buying single components (a pack starts at 110€ on amazon) . When adding smoke/co detectors avoid those with wifi, only the base station SBS050 should be included in your wifi. All other sensors should use the non-wifi radio between base station and devices and coverage is pretty good, so far no problems even with station and devices in different floors (if I remeber correctly they are building some kund of mesh).
You can’t decide how “cheap” these are until you have included the (future) cost of using the API. It’s like with cheap ink printers, the printers are heavily subsidized, but the toner lasts a very short time, and sell at extremely inflated prices. By the time you’ve replaced the toner twice, you’ve already paid more than you did for the printer…
You must think of these things as rentals, not purchases.
The devices seem to have a proper quality, I was able to install many of them without any issues, the App does what you expect (incl. multi home management, shared accounts etc.) and cloud access is for free. Other solutions are also based on a cloud account, pot. exposing data to third parties.
You don’t need to pay for the online service, and if they change the model you could accept it or go for a different solution.
Everyone has to make own decisions and for me it worked out.
I’m just saying that a clear pattern has emerged for devices requiring “cloud APIs” and that don’t offer local APIs (some even remove already existing local APIs, which should tell you all you need about their intent).
The pattern is like this: At first, the API is free and unlimited. Once enough people use it regularly, they start applying restrictions to the free use, combined with some kind of paid “premium subscription” to keep using it without restrictions. Usually, the restrictions get increased a couple of rounds, over some time, so that free use is virtually useless in the end. Then, finally, they just cut the free service.
You now in effect “rent” the use of the device, if you want to use any of the things that require the use of the API.
To top it all off, they can now decide when they want to “deprecate” devices by simply making sure that the API will no longer handle them. They do that when they want to force you to buy new stuff.
Some people defend such behavior with “but they have to cover their cloud costs” etc. But, the point is, that it’s all BS. It’s very easy to offer a local API in most cases, there’s no need to only allow “cloud API” access. And, if they provide a local API, people can use it without any load on their cloud servers. So, why don’t they?
I can only see one reason, and that is because they intend to earn money with the API subscriptions, rather than by selling devices people want to buy. I don’t want people to fall into this trap, so I try to warn them. That’s all.
So, go ahead, use it, but don’t be surprised when this starts happening. Are the devices still “cheap” when you include a monthly subscription to use them? A subscription you don’t even know how much will cost yet..?
My point is that I don’t think it’s if but when. This has nothing to do with X-Sense, but applies to any brand that only offers a cloud API. The thing is that they must make the API anyway, so they don’t “save anything” by not allowing local access. They have intentionally made sure that the API that exists is unavailable to the owner of the device, and I can’t see any other reason for doing this than to extort money from people, and/or to sell their data. It simply makes no sense rationally.
People will go along with it because they have already invested money and effort in installing these devices. They know this, which is why it starts out free. The only way to avoid this trap is to not buy “cloud only” devices in the first place.
Sure, but then they are reduced to regular, “dumb” smoke detectors, that I’m sure that you could buy at a better price/quality combination elsewhere. They always charge extra for “smart”, so if they are really cheap, it probably says lot about the component and sensor quality. Unless it’s backed by people with a lot of money, that are willing to sell them cheap just to get market share, before increasing the prices and enabling the required “rent payment”.
