Eternal problems of the Vera app

Apps & Remote Access VeraMobile
#83

First of all thank you for all of your feedback and support.

As it was already pointed out, these items are not new and they’re standard tools provided provided by use in part with the old platform or provided by our competitors, so all of the items below are part of our roadmap and are today in different stages of our process.

Please see below more details per specific request:

  1. “Bug Tracking”
  2. “Public feature request system”
  3. “Dedicated developer relations”
  4. “A robust, all-inclusive Wiki containing full documentation for each controller, device, feature, etc.”

We are trying to solve for all of these requests with tools that are interlinked and are updated in real time based on out put from our internal tools. We analysed and tested several tools
and we are leaning towards Service Desk from the Atlassian suite. This will allow us to track different types of arequests as well as search through documentation or roadmaps posted in a Confluence workspace.
One of the small setbacks of using this tool is that the users will have access to their own tickets rather than seeing all tickets posted by all users. We’re working on solution for this.

  1. An app store for publishing and installing plugins.

I think it’s safe to say that the appstore we have for the old platform is severly outdated so the plan is to invest a lot of time in building a whole new app store with a lot of new features we’re missing today.
We will soon get started on this initiative and will be able to provide at leas a high level estimate of when this will be available.

  1. Public plugin architecture road map
  2. Development roadmap

We will include in the Confluence workspace a high level version of the roadmap, so users can check it before submitting a new feature request.

3 Likes
#84

Skype is awesome… for talking to my 94-yo m-i-l. I work for a software company. No Skype. Of course, we’re serious about what we develop, too.

2 Likes
#85

Talk? they are not using skype to “talk”…they are using it to “type”…can she type fast? (a chat app is a chat app…you type the other side sees…) Are you saying When you type in skype other party can’t see or type back?

#86

Unless your Skype is set up different from my Skype, it doesn’t provide a permanent history of conversations accessible to anyone later, preventing he-said/she-said debates.

That permanence is important when a feature is 3 or 4 sprints back. MS Teams has history but I doubt you are adding external devs to your Teams, so they don’t have that record.

We use slack for durable chat with people outside the dev group (product owners, SMEs, etc). Then when something useful comes out of the discussion it can get moved to the dev group’s internal docs AND the original discussion is preserved where all current and future participants can access it.

Discord would be another, probably less expensive, option.

2 Likes
#87

Yep and moving pictures. lol

1 Like
#88

And we do use Skype in my company. But only to talk. Not to type.

It has a decent video chat + shared whiteboarding function.

The whiteboards get exported and dropped to docs and/or slack.

1 Like
#89

Exactly the point…you use these kind of tools for realtime communication then take that output and push it internally to Jira or Confluence etc. So the value of skype in the above example as a tool to facilitate realtime communication which then results in internal documents to be created. Ideally internal documents created (with proper ticket numbers etc) would encompass all the discussion therefore historical storage is provided by the internal systems.

And that is what Gabriel said when he mentioned giving access to these…

#90

My point is that impermanent realtime communication is a variant of the telephone. We (modern business) don’t rely on telephone calls alone. That conversation held in real-time is only valuable if it is accurately captured.

The process is calls result in written minutes which are distributed to the attendees and signed off on as accurate. If you don’t have those last two steps, its back to he-said/she-said.

Our ticket system is the start of the process. 'User X needs a thing that does Y." There is a conversation with the user that is captured in the ticket, which the user can see. If the user disagrees with the request as captured, they can document the disputed items in the ticket, which one would hope get addressed prior to scheduling.

There are developer only steps that the user can’t see, but they can tell the tickets status, which usually has a predicted implementation date and/or describes blockers.

Depending on the request, the user may be required to do UAT or provide test cases for validation prior to production deployment.

Release notes will reference the oroginal request ticket when it is deployed.

I have seen some variant of this process as the norm over the past 30yrs.

In my construction engineering days “tickets” were known as “change orders” but its all request tracking, documentation, implementation, and validation.

#91

yup, you are describing the process we follow in the main…

#92

So a developer asks for a thing. They get a ticket number and can log into the system to make sure the ask described is accurate and see the status?

Awesome

2 Likes
#93

I recall the guys over at CyanogenMod (creator of custom ROMs for Android devices, now LineageOS) used precisely such a bug-tracking system, which we beta testers and general users alike could reference.

The value of all that was (a) being able to check whether the bug in question had already been reported, (b) its current status, © add notes to clarify parameters, (d) offer workarounds, and (e) receive notification whenever the ticket updates.

Glad to hear ezlo is already using such a thing internally. Now, imagine how many user-hours could be spared by granting access to everyone, instead of us having to root around (often aimlessly) in the Forum for solutions!!

I am still surprised how long it takes for such system-wide workflow upgrades to implement. Surely the two-way flow of information would be of sufficient benefit as to warrant an hours-to-days timeframe instead of months-years? One can see how developers – accustomed to quick turn-arounds – could get frustrated and bolt.

1 Like
#94

Waiiittt… @melih said the process was mainly as I described.

If 3rd party devs don’t have access to any of it, that’s not the process I described. Which of the 9ish steps i described are not available?

  1. User adds ticket with request 'User X needs a thing that does Y."

  2. Clarifications are captured in the ticket

  3. Can amend the ticket

  4. Ticket is moved to back office

5-8. ticket status is updated at milestones (e.g. queued, in progress, uat, release)

  1. User confirms complete
1 Like
#95

Hi,
good night. the problem happened again. I contacted the technical support, who after a week, told me to install and uninstall the application.

#96

Leave a private message with the serial number and the approx times you encountered the issue. This week we have started optimizing some Alexa related settings and this should have not happened.

Thanks !

#97

@adina.porea need help. the problem happened again. whenever I lose the connection to Wi-Fi and the smartphone changes to 4g, the application stops working. when I leave the house it is problematic because this change is made and the alarms and gates are not activated. I already spoke with the technical support and what they ask me to do delete app ask for the iOS version or the version of the app and then they say they can’t do anything because it’s beyond their capabilities
Ths

#98

Hi everyone,

FYI, the Ezlo Community Bug Tracker is here

Feedback is welcome.
Thanks everyone.

1 Like
#99

good afternoon … The problem continues … there were more people with the same problem. With the new update everything remains the same. It is more than a month that technical assistance is unable to solve the problem. The app update was released 2 days ago and everything remains the same … The app cannot switch from wifi to 4G without having to close the application

#100

good evening. my problem remains the same. I already asked for help on the forum, I already opened a ticket on the website jira.mios, I already spoke with the technical support and everything remains the same … the Vera app when switching from 4G to Wi-Fi or from Wi-Fi to 4G, runs out work … more users have reported the problem. a simple thing like opening and closing the entrance gate of the house, it becomes an impossible task … an example: my smartphone is always connected to the Wi-Fi of the house, when I go out I open the gate with the app, when the car leaves and I try to close the gate the app has already switched from Wi-Fi to 4G, it is immediately blocked and I can’t close the gate … can someone help me?

#101

Same problem here. When I change from 4G to WLAN I have to shoot down the app and restart.

1 Like
#102

it is incredible that they cannot solve this problem that causes so much trouble … a problem with more than 2 years!

Best Home Automation shopping experience. Shop at getvera!

© 2020 Vera Control Ltd., All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules