Local server trouble swapping IOS to Android devices for the same user

Issues and Errors
1

Hi,

I’m having trouble getting my Android devices to work correctly on the local server, although the IOS devices work fine.

I have my Alarm hardware communicating with the local Blynk server, I’ve configured up a dashboard on my ipad and it displays the sensor states correctly, I have a dummy button on the dashboard that can be pressed to keep to keep the app to local server connection alive.

If I logout on my ipad, and login on my iphone everything continues to work correctly. This works for all my IOS devices.

If I logout on my IOS device and login using my Andriod device, none of the sensor states are displayed on the application’s LEDs. Press the button on the Android dashboard and it is sent to the local server and the hardware. Any change in sensor states are sent to the local server, it looks like the server is sending them to the Android app, but it has no effect on the LEDs they are linked to…

This behaviour is consistent for all my Andriod devices.

Where is a good place to start debugging this?

2

I had the same issue, but my Android app wasn’t updated. Have you tried checking the playstore for a new version? I think it’s important to have them both the same (a.k.a. latest) version.

3

Yep, Everything is the alets version, apart from the local server which is still 0.7.4.

4

I’m running local server 0.7. Maybe the issue is there?

5

@NickM Thank you for reporting. I’ll check it.

6

@NickM

Could you please check if your PINs in LEDs where cleaned on Android?

7

Hi,
I’m not sure what you mean by this. Do you want me to recreate the LED widget in the Android? I did this and it didn’t change anything.

I captured some logs, and this is what happens when I use the Android

20:50:14.973 TRACE - Incoming ActivateDashboardMessage{id=3, command=ACTIVATE_DASHBOARD, length=9, body='880762320'}
20:50:14.979 TRACE - Incoming PingMessage{id=4, command=PING, length=0, body=''}
20:50:14.979 TRACE - Incoming HardwareMessage{id=5, command=HARDWARE, length=26, body='pm^@0^@out^@0^@out^@1^@out^@1^@out'}
20:50:18.697 TRACE - Incoming HardwareMessage{id=62, command=HARDWARE, length=6, body='vw^@1^@1'}
20:50:19.698 TRACE - Incoming PingMessage{id=61, command=PING, length=0, body=''}

And this if I use IOS,

21:14:43.254 TRACE - Incoming ActivateDashboardMessage{id=18761, command=ACTIVATE_DASHBOARD, length=9, body='880762320'}
21:14:43.276 TRACE - Incoming HardwareMessage{id=6085, command=HARDWARE, length=14, body='pm^@1^@out^@0^@out'}
21:14:46.613 TRACE - Incoming HardwareMessage{id=41, command=HARDWARE, length=6, body='vw^@1^@1'}
21:14:47.613 TRACE - Incoming PingMessage{id=41, command=PING, length=0, body=''}
21:14:47.614 TRACE - Incoming PingMessage{id=41, command=PING, length=0, body=''}
21:14:47.615 TRACE - Incoming PingMessage{id=41, command=PING, length=0, body=''}
21:14:49.690 TRACE - Incoming HardwareMessage{id=42, command=HARDWARE, length=6, body='vw^@1^@0'}
21:14:50.977 TRACE - Incoming PingMessage{id=9, command=PING, length=0, body=''}
21:14:57.169 TRACE - Incoming DeActivateDashboardMessage{id=14866, command=DEACTIVATE_DASHBOARD, length=9, body='880762320'}

That Pin Management command looks very strange for the Android attempt, for some reason it is trying to set the state twice. This is also what I am seeing in packet captures.

8

I mean when you open Android - go to LED settings and check if LED has selected PIN. Most probably it is empty. So please check this. (This is due to iOS bug that is fixed already and will be published soon).

Regarding

‘pm^@0^@out^@0^@out^@1^@out^@1^@out’

Seems this is another one… Will fix it.

9

Hi,
The pins are assigned in the Android. I’ve never seen it not assign them.

10

Hi,
I manage to solve this. It seems that on the IOS version of the app, it only understands ON and OFF, 1 and 0, so this is all my hardware was writing.

The Android app understands different values for the LEDs, so the 1 I was writing to turn the LED on wasn’t enough, I changed it to 255 for ON and it turns the LED on as expected.

11

Yeap. This is known iOS LED bug. thank you for reporting.

12

In my case also work just selecting low or high