tjabas wrote:is there a way to get the temp widgets to update a little faster?
i think theres aprox. 30 min delay from when a temp change has been made in domoticz, until it is shown in the temp widget.

Patrick89 wrote:I want to post een bug in de android app.
Within de domoticz application there are 2 ip camera's, they both can't get a livesteam!
It looks like it holds it first screenshot and always show it until i refresh the app itself.

A second bug is when i open one of the camera's.
The windows is cropped and the view can't be rotated.
1/3 of the image is cropped off on the phone.

I have the same issue as.above. the app is nog refreshing.
What am i doing wrong?

I'd love for the geofencing to have an option to only use passive cell tower recognition, in order to remove dependency on Google's services and thereby enhance the user's privacy.

The core of the idea is that when the user creates a location, the app doesn't just store its GPS coordinated, but it also looks in an online Cell ID database to find out which cell towers exist around that location, and then stores this data on the phone. From then on the app can compare the cell towers it comes across against the cell towers associated with the location list. As the user gets closer to a location, more of its associated cell towers will come into view. When 90% of them are visible, the user can be said to be at the location.

While it may seem less precise, this method has a number of advantages:

Advantages
- It saves phone battery. If designed according to my proposal (see below), then wifi and/or GPS can stay off. Cellular data usage would also be reduced drastically, as the app won't need to constantly match wifi signals it has picked up against Google's location database.
- It offers better privacy protection. Android's location service constantly sends the ID"s of cell towers and wifi hotspots if comes across to Google's online databases. Google then returns a pretty good estimate of the users location. But it also records that location for its own uses.
- It's precise enough. In most Domoticz use cases medium-to-highly accurate geo positioning isn't necessary. You could even say that the current design of the app underwrites this, as it allows you to set a radius. This implies that being nearby a location, instead of exactly on top of it, is the more useful trigger. (More on this later).
- It's more robust: a phone by definition always knows what cell tower it is in, even when other location services are unavailable (through lack of reception, service, user error or user choice).

Design

- The UX won't have to change, although a fun option would be an "add my current location" button which can directly read the real-world data form the cell towers in the vicinity. The user then gives this location a name, and is done.
- The underlying algorithm could also be simple:

If(go from seeing less than 80% to more than 80% of towers associated with location x) then (send "arriving at x" location signal to Domoticz server).
If(go from seeing more than 20% to less than 20% of towers associated with location x) then (send "leaving x" location signal to Domoticz server).

(This 80-20 design helps to alleviate the "in-out-in-out" problem that often occurs when of a user is on the edge of a location circle in GPS-based systems).

A note on precision
I understand that there are cases where a user wants to select a big or small trigger radius. The app's current system will most likely offer higher precision about the user's location, even down to the centimeter if the user enables GPS. But I would argue that this is overkill:
- Firstly, I would argue that the current app design doesn't really use the precision to its maximum effect because the user can only define locations as a circle. Accurate location data is most useful when you compare against complex location shapes, such as polygons. Then a user could draw precise shapes around buildings, streets or office campus. At the small scale users could define big rooms and gardens. So entering a very precise distance is at odds with the rest of the app's design. This doesn't mean that I want to upgrade to using polygons in the app, quite the opposite:
- I don't think the user really cares about extreme precision either. I think that when they turn to geofencing, users only want to indicate rough distances (a kilometer, 500 meters, 100 meters a.k.a. "when I'm in town, when I'm in my street, when I'm around the corner"). Often users won't be able to precisely guess how far away an intended trigger-distance really is from their home. Do you precisely know how far away your car park is? And if you did, would you want to define the distance that precisely? Even if you did, there is no guarantee that your phone will have accurate location data to measure it against.
The exception here is that people do want to differentiate between being inside their home or outside (trigger security systems, etc). But for this use case the geofencing option will never be consistently precise enough. Other smart home systems will do a better job here, such as a smart lock, a motion sensor, or a user flipping on a light switch.

So while different radii are definitely valuable, I don't think its necessary to be very precise about it. Therefore I think passive cell tower recognition could actually offer a 'good enough' solution:
- To trigger the system at a greater distance, for example to turn up a thermostat before arriving home, the percentage of cell towers that need to be recognized could be lowered. As a users gets closer to the location, more and more cell towers that are associated with that location will pop into view. In the user interface, inputting a radius could be replaced with a slider that allows the user to set a distance, which would correlate with the percentage of the towers that are in view.
- To trigger the system at a smaller distance there are options too. A complex way is by also factoring in the signal strength of the cell towers, or through triangulation. But that's pretty complex to build. Instead I would suggest to use the method described above, but with wifi hotspots instead of cell towers. This would allow for a smaller radius while still preserving passive detection, though at the cost of some privacy (wifi tracking) and of course battery life.

As a side note, precision could also be improved by replacing data from the online database with measured data from the actual real-world locations. These readings would reveal the influence walls and other obstacles have on real-world cell tower availability. Google's services could in theory be avoided here too by asking the user instead: A notification could be given to the user when he or she gets close to a destination. It could ask them to click on it when they are exactly in the middle of the location. When they do, the app replaces the' list it got from the Cell ID database with a new list of actually visible cell towers (and wifi signals) for that location.

A note on the privacy gains
If other apps on the phone are still using Google's location services, then you can argue that the battery and privacy savings are diminished, and Google will still be able to track you. While this is true, I still think its still relevant to build this feature, for a number of reasons. Firstly, this is a really valuable feature to privacy-aware users (such as me) who do manage these aspects. More over, I suspect a lot of of Domoticz users are privacy aware. They probably understand the values and freedoms that open source software brings, and are using Domoticz to purposefully avoid commercial cloud-based solutions. Thirdly, the open source world is a good place to explore and showcase new value sensitive designs and privacy enhancing technologies. This could be one of those.

Design, part 2
In any case, I'm not advocating to replace the current location system. Perhaps through settings, or when first opens the geofencing option in the app, the user could be given a choice so they themselves can make the trade-off between required levels of precision and desired privacy protection, and thus between the two methocs. Something like:

A. Simple - most privacy and battery friendly. The app will know you have arrived when it recognizes the unique combination of cellular towers at at each destination. This method is less precise, but saves battery. It enhances your privacy because it doesn't rely on Google's services for location tracking. (This is the method described above)
B. Medium - actions are triggered based on the proximity of wifi hotspots instead of cell towers, which allows for more precision. While your location data is still not sent to Google, your wifi signal can be picked up as you travel. Scanning for wifi signals will also reduce your battery life. (This is a variation on the method described above)
C. Precise - this allows you to set a precise radius around a location, but at the cost of battery life and privacy, as it uses Google's location services to track your location. (This is the app's current system)

Ok, this has become the longest feature request I have ever done. I hope this is not perceived as a criticism in any way, as I thoroughly respect the great and selfless work that has already gone into this app already. I only with to contribute to it.

HAHA, ok, I just found out that Samsung and some other phones don't support getting the ID's of nearby cell towers. I guess that lessens the incentive to implement this feature request.

An option would be to simplify the request: could the app just toggle locations by checking if it is connected to certain Cell ID's? This would also mean that in order to add a new location, the user would have to physically go to those locations first and then click an "add this location" button. The app then stores the ID of the connected cell tower, and from then on the app just checks it if has reconnected.

I have a remote for my fireplace which is listed as a Thermostat3. In the Domoticz website when I click on the on/off, it gives me a set of buttons for UP and DOWN too, but in the Domoticz Android App, I can only switch it ON and OFF. Do I have to change a setting for this, or is it just not implemented (yet)?

Jeroen1981 wrote:I have a remote for my fireplace which is listed as a Thermostat3. In the Domoticz website when I click on the on/off, it gives me a set of buttons for UP and DOWN too, but in the Domoticz Android App, I can only switch it ON and OFF. Do I have to change a setting for this, or is it just not implemented (yet)?

Please PM me, maybe you could create a viewer account for me so I can debug your system.

i think that the seletor switch dont work fine, i will write my example.

i have te seletor with OFF/5 MIN/ 10 MIN/15 MIN

if the seletor are off, dont appear the list that we want switch so i have to enable first and now will appear the first level, it 5 Min, but to put 5 Min working i have to switch to other level and go back again to 5 Min, mean while the other level start work and 5 Min too.

tjabas wrote:i have just installed a Oregon Scientific PCR 800 rain gauge, i have added a wiget to my homescreen(android), but why does it show some strange numbers, why doesnt it show the correct data?

tjabas wrote:i have just installed a Oregon Scientific PCR 800 rain gauge, i have added a wiget to my homescreen(android), but why does it show some strange numbers, why doesnt it show the correct data?

NiklasO wrote:Getting quite annoyed getting told to get the premium version when trying to add widgets. I have payed for the app.

You've installed the app from the play store directly?
Did you import the settings of the lite version?

Anyone else having this issue?

Well, when thinking about it, I have changed my phone in november and then I could add the widgets (and still have them) but I can't add new ones. Haven't tried for a while but wanted to try the new widget for blinds. I can't find anything about buying the premium version in the app and yes, bought in play store and using the beta version. It's not the lite version. https://drive.google.com/file/d/0B13H1M ... sp=sharing