Kamore X1 Pro - Communication Timeout

[fodsod]

Yes, the plan is saved on the device. My pumps continued dosing like normal even with this issue.

Same for both of mine. Had a connection issue same as others but my pumps stayed on schedule.

 

[BigMax]

Same for both of mine. Had a connection issue same as others but my pumps stayed on schedule.

Greetings fodsod. I'm struggling to understand how the app and the device time clock can be completely out of sync and yet dose to a set schedule, you would think the app when opened, or performing a time resync would always reset the device. You may be right, but that absolutely makes no sense to me. The app clock must have control otherwise the app is worthless, but if you never open the app or re-sync the clock that could work, but seems like a silly workaround, as you may as well just use a non Wi-Fi device at that point. If you're running the device independent of the network / Wi-Fi I would understand the no impact statement.

Things need to make sense to me before I can accept it

 

[fodsod]

Greetings fodsod. I'm struggling to understand how the app and the device time clock can be completely out of sync and yet dose to a set schedule, you would think the app when opened would always reset the device. You may be right, but that absolutely makes no sense to me. That would me the app clock has no control, so if you never open the app or re-sync the clock that could work, but seems like a silly workaround. If your running the device independent of the network / wifi I would understand it.

Things need to make sense to me before I can accept it

I'm certainly no expert, but what seems to be one of the issues is the time sync and general sync between the firmware (what's actually running the pumps) and the app (your control of the firmware).

It appears to me that the firmware running the pumps is operating as initially set up for whatever schedule the user programmed but the sync (for us to see what's going on via the app) has a bug that rears it's head at times.

So we open the app to check the status and sometimes it's correct to the what was programmed and sometimes we can't see anything due to the glitch.

That's my experience at least. I check mine almost daily and screen shot the progress when I have the app open so I can compare the total amounts dosed over the period from when I last checked. Simple math and the screen shots allows me to see if the proper amount has been dosed over that period of time.

Hope this makes sense.

 

[GT3000XX]

I have been in touch with Coralvue and just received the following response:

“We have reached out to Kamoer about this issue as there is a problem with the server. Once the server is fixed your unit should work correctly.”

 

[BigMax]

I'm certainly no expert, but what seems to be one of the issues is the time sync and general sync between the firmware (what's actually running the pumps) and the app (your control of the firmware).

It appears to me that the firmware running the pumps is operating as initially set up for whatever schedule the user programmed but the sync (for us to see what's going on via the app) has a bug that rears it's head at times.

So we open the app to check the status and sometimes it's correct to the what was programmed and sometimes we can't see anything due to the glitch.

That's my experience at least. I check mine almost daily and screen shot the progress when I have the app open so I can compare the total amounts dosed over the period from when I last checked. Simple math and the screen shots allows me to see if the proper amount has been dosed over that period of time.

Hope this makes sense.

Thanks for the response. In essence you are treating this as non-wifi device, set and forget. Given the reliability of their application this is probably the best path, seriously. You may have the best approach.

Per your comments if the internal clock is left uncorrupted it performs as last set, to the times and amounts desired during a 24 hour period.

As you say there has to be an internal clock that controls the device. Maybe its best when checking the app that if you see an appropriate time for the 'App Time' in the settings page then you can perform a 'time sync'. I can't recall if the time is way off if it will even allow you to perform a time sync, or it will just timeout when sync time is pressed?

If the clock is corrupted by syncing it to the app you would get the same dosing amount during a 24 hour period, if set to daily dosing, but not at the times specified. ( The only under or over doses would be in the widow of the app time offset to actual time when performing a resync).

I'm over thinking this as usual But at a minimum Kamores' code writers have work to do, they need a better solution to performing FW updates (assuming they have a fix for the current problems) than the 2 cell phone routine.

 

[BigMax]

I have been in touch with Coralvue and just received the following response:

“We have reached out to Kamoer about this issue as there is a problem with the server. Once the server is fixed your unit should work correctly.”

I'm curious if we will then be able to update the firmware without the 2 phone hotspot routine? The hotspot routine was relatively straight forward, but for me when binding and reaching 60% complete I get a 'provisional timeout' message. Regardless, not an acceptable process.

 

[fodsod]

Thanks for the response. In essence you are treating this a non-wifi device, set and forget. Given the reliability of their application this is probably the best path, seriously. You may have the best approach.

Per your comments if the internal clock is left uncorrupted it performs as last set, to the times and amounts desired during a 24 hour period.

As you say there has to be an internal clock that controls the device. Maybe its best when checking the app that if you see an appropriate time for the 'App Time' in the settings page then you can perform a 'time sync'. I can't recall if the time is way off if it will even allow you to perform a time sync, or it will just timeout when sync time is pressed?

If the clock is corrupted by syncing it to the app you would get the same dosing amount during a 24 hour period, if set to daily dosing, but not at the times specified. ( The only under or over doses would be in the widow of the app time offset to actual time when performing a resync).

I'm over thinking this as usual But at a minimum Kamores' code writers have work to do, they need a better solution to performing FW updates (assuming they have a fix for the current problems) than the 2 cell phone routine

I agree that the programming needs some work. Not cool at all to try and check on my dosing and not be able to see that everything is going as it should.

If I'm not mistaken, if you look at the time sync it's the app time that is matched to the device time not the other way around. So the original programming the user does to the device via the app and then saves that program is what drives the devices. The app is just a doorway into the device's operating system essentially.

Either way, it appears at least on my end that once I've set the programming and saved it then the devices will operate as programmed regardless of what the app is doing until the app is used to change the programming of the device.

One of the big selling points of the X1 Pro 2 was the fact that it would hold your programming in memory if the power was out or you unplugged it. The previous models didn't hold the programming. So that alone shows the device can retain programming regardless of the app's status.

 

[GT3000XX]

I asked CoralVue about whether the unit stores time and dosing schedules here is the reply:

The dosers keep there schedule regardless if it is connected to the wifi. Connection is needed to manually dose, calibrate, change the schedule or amounts, update the firmware or time.

I noticed the last word is time. I have asked CoralVue if the time will remain accurate when the unit won't connect to the server.

 

[fodsod]

I asked CoralVue about whether the unit stores time and dosing schedules here is the reply:

The dosers keep there schedule regardless if it is connected to the wifi. Connection is needed to manually dose, calibrate, change the schedule or amounts, update the firmware or time.

I noticed the last word is time. I have asked CoralVue if the time will remain accurate when the unit won't connect to the server.

Good that you asked as I'd like them to confirm what I'm already assuming.

I'd think that if the doser's functionality has the ability to maintain the programmed schedule, total amount dosed and dose amount (time is required to stay on schedule) then there's no reason why time shouldn't remain active and accurate based on when you programmed it last.

Now if you were updating (syncing the time) or any other task that requires an update from the server via the app or a direct firmware upgrade from them then the WiFi connection is needed.

Having said that, I'm still experiencing a lot of "time out connection" issues in the evenings. It takes me several minutes to get the app to connect to the individual dosers to see the details or make changes. Not sure what's going on. When it does eventually connect everything is correct but it's still irritating to deal with.

I guess that's the price paid for spending 1/3 of the cost of the "better" dosers.

 

[BigMax]

I'm a little dumbfounded as well. As fodsod mentioned there is a 'clock' resident on the device. But when the cloud comes back up, and the communication link is functional, both the App Time and Firmware Time are wrong....if the FW time is a direct feedback from the doser coming back on line than in my case it device FW clock was more than an hour off when it last came back on line. Hope the explanation makes sense?

Both App and FW time were wrong, but also not the same as each other. After as time sync is allowed (obviously) FW, App an actual time are all in sync.

I have the Kamore in my home office and am monitoring it. I'm using an old Jebao doser in the interim, no bells, whistles or app but I know it will perform as programmed.

 

[GT3000XX]

I agree with all the comments. The best thing we can do is to overwhelm CoralVue with support requests. I’m sure if they become overwhelmed the fix will happen faster.

 

[fodsod]

Not add fuel to the fire on this but I took this screen shot when I was checking the time sync function earlier today. Notice the 7/11/2018.

I've noticed this several times but just ignored it because it always updates to the correct time/date when it connects. Not sure what's going on with showing a default time and date verses the last saved time and date.

 

[GT3000XX]

Not add fuel to the fire on this but I took this screen shot when I was checking the time sync function earlier today. Notice the 7/11/2018.

I've noticed this several times but just ignored it because it always updates to the correct time/date when it connects. Not sure what's going on with showing a default time and date verses the last saved time and date.

You are correct mine says the same. So is CoralVu feeding us a line? I would say if the firmware says that time and date that would be what the unit goes by.

 

[GT3000XX]

Just received from CoralVu that Kamoer wants my username and password to research the issue. I politely told CoralVu that’s not happening they should be able to figure that out without my info.

 

[EugeneVan]

Are you guys connecting your Kamoer to the 5G or 2.4G wireless network? I ran 9 of them on 2.4G wireless network for over 2 years and never failed the connection expected my internet service provider was down.

 

[fodsod]

Mine is on 2.4. I have 2 currently.

 

[EugeneVan]

And all 8 of them are on firmware 1.0.8 and X1_PRO_EN-1.1.06

 

[fodsod]

You are correct mine says the same. So is CoralVu feeding us a line? I would say if the firmware says that time and date that would be what the unit goes by.

I'd guess that's a default data point for the app not the firmware. They probably needed a default date/time when coding the programming for the app to start with and the app defaults to that rather than the last time the user logged in due to the rudimentary coding they used to get the app out in time.

When we log in and initiate the app to connect then it reaches into the actual firmware data and produces the current date and time. Again, could've been coded that way or there's a task that's failing in the back ground to keep the app updated to the last time the user logged in.

Either way, it's lazy programming or just poorly done. Probably rushed it to market and paid some hack to write and code in a very basic form.

 

[BigMax]

I'm running 2.4GHz and on-line. I saw someone, with the same failure mode, mention they only had there device for about 3 weeks as well. I'm beginning to wonder if they had a bad FW release for units in production during given window and that they have not found a way to write over it from the cloud, such that older units work fine, like mentioned by others, and we're just unlucky? My FW shows up as either null, or 1.0.7 when functioning. The device is always on line and I can manually dose even when receiving communication time outs, so I am able to communicate with the device over Wi-Fi all the time.

I also see there are later versions of FW than 1.0.7 but when the unit is communicating properly it shows FW 'up to date' even though it isn't current and therefore will not allow you to update. If I don't hear anything from CoralVue by the end of the week I'll contact them to send it to CoralVue for a FW update, which I can't do even with the 2 phone hotspot. Based on the cost of this thing I'm probably better off just tossing it, but it's hard not trying to get it working.

Another thought is the electronics components themselves, all manufacturers. in this case Kamore, have multiple suppliers for all components, maybe there is a HW compatibility issue during production in this time frame that they are not aware of?

 

[Jason Jordan]

In case everybody hasn't said it enough yet...this is ridiculous! i just got 4 of these on Monday and cant get them up and running.