Turn device on doesn't work after factory reset about xled HOT 3 CLOSED

Apparently return value isn't passed across multiple layers. And in the end CLI tool doesn't check return value.

With this quick debug:

diff --git a/xled/cli.py b/xled/cli.py
index 905bc8a..c369d92 100644
--- a/xled/cli.py
+++ b/xled/cli.py
@@ -104,7 +104,8 @@ def get_mode(ctx):
 def turn_on(ctx):
     control_interface = common_preamble(ctx.obj.get("name"), ctx.obj.get("hostname"))
     log.debug("Turning on...")
-    control_interface.turn_on()
+    retval = control_interface.turn_on()
+    click.echo(retval.status_code)
     click.echo("Turned on.")
 
 
diff --git a/xled/control.py b/xled/control.py
index 072e444..7a42b17 100644
--- a/xled/control.py
+++ b/xled/control.py
@@ -329,6 +329,7 @@ class ControlInterface(object):
         app_response = ApplicationResponse(response)
         required_keys = [u"code"]
         assert all(key in app_response.keys() for key in required_keys)
+        return app_response
 
     def set_led_movie_full(self, movie):
         """

An status code: 1104 is printed.

Application apparently continues with call:

{
"mode": "effect",
"effect_id": 0
}

I guess CLI tool/high level interface should do the same.

from xled.

I stumbled upon this myself, and think I understand why it happens:

After factory reset, the led movie config parameters "frame_delay" and "frames_number" are both set to zero, because of course there is no movie uploaded yet. In this situation it refuses to go into "movie" mode, which actually makes sense.

In my resent pull request #80 to enhance the control interface I have included a fix for this. What I do to handle it is twofold:

First, when uploading a movie, the commands are run in the reverse order to the previous code: first set the movie parameters, then upload the movie, and finally switch to movie mode. Then it works fine, also the first time, since the movie is uploaded when trying to switch the mode.

Second, when running "turn_on", the new code tries to remember what mode was used last and returns to that, unless it is the first time, in which case the code checks the movie parameters and only goes to movie mode if there is a non-zero number of uploaded frames, and goes to "effects" mode otherwise (which seems to be the default mode after factory reset, and consistent with the log above).

/ Anders Holst

from xled.

After factory reset, the led movie config parameters "frame_delay" and "frames_number" are both set to zero, because of course there is no movie uploaded yet. In this situation it refuses to go into "movie" mode, which actually makes sense.

@Anders-Holst I have looked into this and indeed these two values are set to 0. On the top of that, while frames_number could be set to 0 by API, frame_delay doesn't accept 0 so it would be possible to determine factory reset out from this heuristic.

But in the end I have looked into traffic from the app (3.3.8) against device with lowest FW version I got handy (2.6.2) and it clearly tries to set mode: "playlist", if that doesn't work it continues with "movie" and if that doesn't work either it ends up with "effect".

Rather than using heuristic and internal state, which CLI wouldn't use, I ended up implementing the same logic in #124.

from xled.