Hue emulation Alexa works but says "this value is outside the range of the device"

[yonaesp]

I'm using dual sonoff, with wemo it only detects one relay, with hue detecting both and it works perfectly when I say "Alexa, turn on button 1", normally alexa must answer "ok" but in this case he answers "this value is outside the range of the device" however, it turns on and off without problem, and when I use "Alexa, turn off the button 1" it responds correctly "ok".

My device is in Spanish since I am participating in the closed beta, it is likely that in English it will respond with a different word as indicated here: 1639

I have also tried modifying the line indicated in this comment, 360218536 recompiling the firmware and installing it, but the problem persists.

Another problem that I have, from the alexa app I can turn on the relays but I can not turn them off, however using the voice command if I can do it.

this only happens to me with hue emulation.

[Jason2866]

Maybe the name button 1 is for Alexa iritating. Change it to something common. Maybe you try light as name. In general that is not a Tasmota problem! I use Alexa too, and it works perfect hrre in Germany.

[yonaesp]

The real name is "Arriba/Up", button 1 is only an example.

[Jason2866]

"/" is not allowed just a simple usual word

[yonaesp]

it's only "Arriba" ( /up is the translation that I have used here as an informative).

[Jason2866]

Maybe Alexa isnt working like it should since it is in beta state in your region. This help you not at all, but Tasmota is working correct with HueEmulation with Alexa in countrys where is official supported

[yonaesp]

Is possible, Here (Green = Translation to English) I attach some images of what appears in the app Alexa to see if that can indicate something.

I do not have any Skills activated, should I activate any?

It also does not allow me to edit the button settings

[Jason2866]

No skill is needed to activate. Changing names edit button works here (Germany). My setup looks like this.

[yonaesp]

from what I see you does not show any error, therefore it seems clear that this is a problem with the beta version.

thanks for your help, the solution will be to wait then :D

[Jason2866]

Your welcome, please close this issue.

[yonaesp]

In the uk version has the same problem, so it is not something related to the beta of Spain.

@Jason2866 If you do not get that error when you turn it on, I would like you to tell me how you have configured your sonoff, hue bridge? mqtt enabled? I do not understand why you do not have this error and others do, maybe some parameter configured differently

[Jason2866]

@yonaesp Config: Hue Bridge, mqtt, web, disabled mDNS, disabled Domoticz, disabled HomeAssistant Simple Friendly Name (only letters) -> "speakable" Tasmota v.6.1.1b with arduino core 2.3.0 (this is urgent!)

[yonaesp]

@Jason2866 How can I get the version you mention? (6.1.1b 2.3.0) I do not see that version here https://github.com/arendst/Sonoff-Tasmota/releases

should I join files and compile my own firmware? thanks!

[yonaesp]

@Jason2866 I download, configure and compile with 2.3.0 the firmware: 6.1.1b-mod-1.35.2 using arduino IDE. but the problem persists, I still do not understand why you alexa does not answer this message when you turn on the devices. I think I have nothing left to check.

Do you have any installed skill related to hue or ifttt? thanks.

[Jason2866]

No skill installed. No ifttt Alexa always answers with ok for on and off

[ascillato2]

Hi,

Have you managed to solve your issue?

[yonaesp]

@ascillato2 No, I still do not understand why jason2866 does not have this problem. It happens in the Spanish and English versions, I have tried different tasmota versions and it remains, I still do not know what the error is associated with.

@Jason2866 can you share your firmware.bin here please?

[Jason2866]

@yonaesp I cant share because i use hard coded wifi credentials. Deleted the wifi config part to save space. In earlier versions i did this myself (not as elegant as @arendst) . Since 6.1.1 this is a option :-) If you mail me your wifi settings i could compile your version of my used setup. Maybe this version is not a good choice for you. I disabled options i will never use (wificonfig, Domoticz, all things belong to Hass, mDNS)

[yonaesp]

@Jason2866 OK, tell me where I can contact you to send you the credentials.

When I try to install the firmware using 2.3.0, after restarting the sonoff never started again since in arduino ide it did not allow selecting more than 500kb of memory with that version.

[Jason2866]

Your version firmware.zip Good Luck!

[yonaesp]

@Jason2866 the problem persists, perhaps in the German version is implemented correctly alexa and in uk and spain not yet.

I guess we just have to wait and report the error to Amazon directly. Thank you very much for your time and help, greetings!

[Boris16]

Hi, I have the same problem (sporadic).

First I flash a Wemos D1 Mini and it works fine. Second I flashed a Sonoff Basic R2 V1.0 (2017-10-11) with Tasmota 6.1.1 german. To use the GPO14, I use the hue bridge emulation.

Sometimes Alexa found a lamp with color adjustment and sometimes a normal lamp. When the lamp with color setting is found, Alexa will give the info "this value is outside the range of the device" at the power-on command. As mentioned above "sporadically". After deleting the device and search it again, sometimes the lamp without color setting is found. And then it works without "this value is outside the range of the device".

So far I have not had any problems with the Wemos D1 Mini.

Is it possible to parameterize Tasmota in such a way that hue bridge emulation always detects a lamp without color management?

[nospam2000]

I have the same problem with a Sonoff 4CH-R2: the lamps can be switched on, but not off. They are detected as dimmable color lamps. Alexa cannot read the state of the lamp.

Also from my side the question: How is it possible to select a simple on/off lamp instead of a dimmable multicolor lamp?

I'm in Germany, but I use the standard english localization. I don't have an MQTT server.

[nospam2000]

They are detected as dimmable color lamps.

When I remove the "lamps" in the Alexa app and let Alexa rediscover the lamps, the type may change to simple on/off lamp. This worked for 3 out of 4 lamps, for the 4th lamp I had to remove and add it again. Even then it didn't work.

[thylonius]

Hi all, I discovered that the issue is related to the response of tasmota. Tasmota for now reports new devices always as „extended color lights“, and therefore Alexa sends not only state change commands, but as well brightness setting etc. when tasmota is configured as simple switch without any special light features (light_type ==0) a response from tasmota is replying with the correct state change but brightness etc. will be reported back to Alexa as „0“. To fix this simply (I know it is ugly, but plan to create a pull request): go to xplg_wemohue.ino And change within function HueLightStatus1 the first if condition to update the hue, sat, bri unconditionaly:

//if (light_type) { LightGetHsb(&hue, &sat, &bri); //}

I said it‘s ugly. But it would require a proper design and separate configurability of light_type. You will notice that you won‘t be able to set brightness etc as a device Independent value in the Alexa app. As far as I understand from your usecases that won’t matter much.

Regards

[thylonius]

Further notice: more elegant way would also be to change tasmota to report devices as „on/off light“. You could do this by changing the JSON responses. For now I was able to change tasmota to report only „on/off light“, but still struggling with the state responses ...will report here if it turns out well.

Regards

[nobodyAtall]

@thylonius

Tried your workaround in xplg_wemohue.ino but didn't make much difference. Device is detected in Alexa but it either says:

• Device doesn't support requested value or
• Device is unresponsive

Toggling the sonoff on, works. But it won't turn again off via the Alexa app.

Also seeing this in the HA journal:

journalctl -f -u home-assistant@homeassistant

Aug 23 00:34:19 osmc hass[20222]: Traceback (most recent call last): Aug 23 00:34:19 osmc hass[20222]: File "/srv/homeassistant/lib/python3.5/site-packages/aiohttp/web_protocol.py", line 378, in start Aug 23 00:34:19 osmc hass[20222]: resp = await self._request_handler(request) Aug 23 00:34:19 osmc hass[20222]: File "/srv/homeassistant/lib/python3.5/site-packages/aiohttp/web_app.py", line 341, in _handle Aug 23 00:34:19 osmc hass[20222]: resp = await handler(request) Aug 23 00:34:19 osmc hass[20222]: File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/http/view.py", line 113, in handle Aug 23 00:34:19 osmc hass[20222]: result = await result Aug 23 00:34:19 osmc hass[20222]: File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/emulated_hue/hue_api.py", line 177, in put Aug 23 00:34:19 osmc hass[20222]: parsed = parse_hue_api_put_light_body(request_json, entity) Aug 23 00:34:19 osmc hass[20222]: File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/emulated_hue/hue_api.py", line 324, in parse_hue_api_put_light_body Aug 23 00:34:19 osmc hass[20222]: return (result, brightness) if report_brightness else (result, None) Aug 23 00:34:19 osmc hass[20222]: UnboundLocalError: local variable 'report_brightness' referenced before assignment

[thylonius]

Hi, Could you send me your modified ino file? I would like to compare with mine...earliest tomorrow, quite late already. Have you removed all depencies on light_type in the file? Could also be possible that I messed up.

RegardS

Am 22.08.2018 um 23:35 schrieb Vassilis Tsogkas notifications@github.com:

@thylonius

Tried your workaround in xplg_wemohue.ino but didn't make much difference. Device is detected in Alexa but it either says:

Device doesn't support requested value or Device is unresponsive Toggling the sonoff on, works. But it won't turn again off via the Alexa app.

Also seeing this in the HA journal:

journalctl -f -u home-assistant@homeassistant

Aug 23 00:34:19 osmc hass[20222]: Traceback (most recent call last): Aug 23 00:34:19 osmc hass[20222]: File "/srv/homeassistant/lib/python3.5/site-packages/aiohttp/web_protocol.py", line 378, in start Aug 23 00:34:19 osmc hass[20222]: resp = await self._request_handler(request) Aug 23 00:34:19 osmc hass[20222]: File "/srv/homeassistant/lib/python3.5/site-packages/aiohttp/web_app.py", line 341, in _handle Aug 23 00:34:19 osmc hass[20222]: resp = await handler(request) Aug 23 00:34:19 osmc hass[20222]: File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/http/view.py", line 113, in handle Aug 23 00:34:19 osmc hass[20222]: result = await result Aug 23 00:34:19 osmc hass[20222]: File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/emulated_hue/hue_api.py", line 177, in put Aug 23 00:34:19 osmc hass[20222]: parsed = parse_hue_api_put_light_body(request_json, entity) Aug 23 00:34:19 osmc hass[20222]: File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/emulated_hue/hue_api.py", line 324, in parse_hue_api_put_light_body Aug 23 00:34:19 osmc hass[20222]: return (result, brightness) if report_brightness else (result, None) Aug 23 00:34:19 osmc hass[20222]: UnboundLocalError: local variable 'report_brightness' referenced before assignment

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[nospam2000]

I tried to patch the detected type and emulate an Osram socket by replacing these two defintions in sonoff/xplg_wemohue.ino:

const char HUE_LIGHTS_STATUS_JSON[] PROGMEM =
  "{\"on\":{state},"
  "\"alert\":\"none\","
  "\"mode\":\"homeautomation\","
  "\"reachable\": true}";

const char HUE_LIGHTS_STATUS_JSON2[] PROGMEM =
",\"type\":\"On/Off plug-in unit\","
"\"name\":\"{j1\","
"\"modelid\":\"Plug 01\","
"\"manufacturername\":\"OSRAM\","
"\"productname\":\"On/Off plug\","
"\"capabilities\":{"
  "\"certified\":false,"
  "\"control\":{},"
  "\"streaming\":{"
    "\"renderer\":false,"
    "\"proxy\":false"
  "}"
"},"
"\"config\":{"
  "\"archetype\":\"classicbulb\","
  "\"function\":\"functional\","
  "\"direction\":\"omnidirectional\""
"},"
"\"uniqueid\":\"{j2\","
"\"swversion\":\"V1.04.12\"}";

unfortunately I was not able to download the modified firmware, because my USB serial converter gave up. Maybe someone of you can check this out.

[nobodyAtall]

@nospam2000 Same behavior with your suggested change:

Aug 24 01:13:25 osmc hass[5143]: Traceback (most recent call last): Aug 24 01:13:25 osmc hass[5143]: File "/srv/homeassistant/lib/python3.5/site-packages/aiohttp/web_protocol.py", line 378, in start Aug 24 01:13:25 osmc hass[5143]: resp = await self._request_handler(request) Aug 24 01:13:25 osmc hass[5143]: File "/srv/homeassistant/lib/python3.5/site-packages/aiohttp/web_app.py", line 341, in _handle Aug 24 01:13:25 osmc hass[5143]: resp = await handler(request) Aug 24 01:13:25 osmc hass[5143]: File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/http/view.py", line 113, in handle Aug 24 01:13:25 osmc hass[5143]: result = await result Aug 24 01:13:25 osmc hass[5143]: File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/emulated_hue/hue_api.py", line 177, in put Aug 24 01:13:25 osmc hass[5143]: parsed = parse_hue_api_put_light_body(request_json, entity) Aug 24 01:13:25 osmc hass[5143]: File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/emulated_hue/hue_api.py", line 324, in parse_hue_api_put_light_body Aug 24 01:13:25 osmc hass[5143]: return (result, brightness) if report_brightness else (result, None) Aug 24 01:13:25 osmc hass[5143]: UnboundLocalError: local variable 'report_brightness' referenced before assignment

@thylonius this is the file I used (attached) xplg_wemohue.ino.txt

[nobodyAtall]

My related HA config:

...

mqtt: broker: 192.168.1.51 discovery: true

discovery_prefix: homeassistant

username: DEVuser password: DEVpw

switch:

• platform: mqtt name: "Sonoff Switch 01" command_topic: "cmnd/sonoffDEV1/power" state_topic: "stat/sonoffDEV1/POWER" qos: 1 payload_on: "ON" payload_off: "OFF" retain: true
• platform: mqtt name: "Sonoff Switch 02" command_topic: "cmnd/sonoffDEV2/power" state_topic: "stat/sonoffDEV2/POWER" qos: 1 payload_on: "ON" payload_off: "OFF" retain: true
• platform: mqtt name: "Sonoff Plug 01" command_topic: "cmnd/sonoffPLUG1/power" state_topic: "stat/sonoffPLUG1/POWER" qos: 1 payload_on: "ON" payload_off: "OFF" retain: true ...

[thylonius]

@nobodyAtall

Used your file in my config to be sure. For me it does work. How could we find differences? Could you explain where you log that traces of yours and what the link with homeassistant? I do not use any other infratructure than alexa (as voice command interface mainly). I emulate 4 devices on ESP-12E Board with tasmota v6.1.1. (Controlling a hydroponic system in my garden)

Program Version 6.1.1 Build Date & Time 2018-08-24T10:41:18 (< with your file) Core/SDK Version 2_3_0/1.5.3(aec24ac9) Uptime 0T00:11:46 Flash write Count 5189 at F8000 Boot Count 2008 Restart Reason Software/System restart Friendly Name 1 Wasser1 Friendly Name 2 Wasser2 Friendly Name 3 Wasser3 Friendly Name 4 Wasser4 Jörg

[nospam2000]

I have changed 2 things in my definition, now it is working for me:

1. removed the blank in the "reachable" line
2. added the "swupdate" section now two of four channels of my Sonoff 4CH are working. There is lots of random going on ...

   
   const char HUE_LIGHTS_STATUS_JSON[] PROGMEM =
   "{\"on\":{state},"
   "\"alert\":\"none\","
   "\"mode\":\"homeautomation\","
   "\"reachable\":true}";

const char HUE_LIGHTS_STATUS_JSON2[] PROGMEM = ",\"swupdate\": {" "\"state\": \"notupdatable\"," "\"lastinstall\": null" "}," "\"type\":\"On/Off plug-in unit\"," "\"name\":\"{j1\"," "\"modelid\":\"Plug 01\"," "\"manufacturername\":\"OSRAM\"," "\"productname\":\"On/Off plug\"," "\"capabilities\":{" "\"certified\":false," "\"control\":{}," "\"streaming\":{" "\"renderer\":false," "\"proxy\":false" "}" "}," "\"config\":{" "\"archetype\":\"classicbulb\"," "\"function\":\"functional\"," "\"direction\":\"omnidirectional\"" "}," "\"uniqueid\":\"{j2\"," "\"swversion\":\"V1.04.12\"}";

[nospam2000]

after adding these line:

  while(path->endsWith("/")) {                        // remove trailing "/"
    path->remove(path->length() - 1, 1);
  }

after path->remove(0, 4); // remove /api

in sonoff/xplg_wemohue.ino, all of my 4 channels were working. As I said above this might be totally random, but at least the responses now also work when the requests end with "/"

[nobodyAtall]

@nospam2000 Thanks, can you post your xplg_wemohue.ino file?

[nospam2000]

@nobodyAtall: I have lot's of stuff in xplg_wemohue.ino which would cause more confusion (e.g. additional logging and commented sections). Let me tidy it up first. I will probably create a new git branch.

I'm still in the evaluation phase and try to figure out why sometimes 3 and sometimes only 1 device is detected correctly. In my previous try it seemed to make difference if a lamp is switched on or off, but in the next try I could not confirm that theory.

[nospam2000]

@nobodyAtall I switched now to the git HEAD version and reverted all unneeded changes. For a simple on/off contact this works fine, for a multicolor the original response string needs to be adapted, for example there is a space in "xy" after the comma: "xy":[0.5, 0.5]

Here the diff, including the dump of the response:

diff --git a/sonoff/xplg_wemohue.ino b/sonoff/xplg_wemohue.ino
index 9a7cdee..ef68e4a 100644
--- a/sonoff/xplg_wemohue.ino
+++ b/sonoff/xplg_wemohue.ino
@@ -453,14 +453,14 @@ const char HUE_DESCRIPTION_XML[] PROGMEM =
   "\r\n";
 const char HUE_LIGHTS_STATUS_JSON[] PROGMEM =
   "{\"on\":{state},"
-  "\"bri\":{b},"
-  "\"hue\":{h},"
-  "\"sat\":{s},"
-  "\"xy\":[0.5, 0.5],"
-  "\"ct\":500,"
+//  "\"bri\":{b},"
+//  "\"hue\":{h},"
+//  "\"sat\":{s},"
+//  "\"xy\":[0.5,0.5],"
+//  "\"ct\":500,"
   "\"alert\":\"none\","
   "\"effect\":\"none\","
-  "\"colormode\":\"hs\","
+//  "\"colormode\":\"hs\","
   "\"reachable\":true}";
 const char HUE_LIGHTS_STATUS_JSON2[] PROGMEM =
   ",\"type\":\"Extended color light\","
@@ -756,6 +756,9 @@ void HueLights(String *path)
   else {
     WebServer->send(406, FPSTR(HDR_CTYPE_JSON), "{}");
   }
+
+  snprintf_P(log_data, sizeof(log_data), PSTR(D_LOG_HTTP D_HUE_API " (%s)"), response.c_str());
+  AddLog(LOG_LEVEL_DEBUG_MORE);
 }

 void HueGroups(String *path)
@@ -792,6 +795,10 @@ void HandleHueApi(String *path)
   uint8_t args = 0;

   path->remove(0, 4);                                // remove /api
+  while(path->endsWith("/")) {                        // remove trailing "/"
+    path->remove(path->length() - 1, 1);
+  }
+
   uint16_t apilen = path->length();
   snprintf_P(log_data, sizeof(log_data), PSTR(D_LOG_HTTP D_HUE_API " (%s)"), path->c_str());
   AddLog(LOG_LEVEL_DEBUG_MORE);                      // HTP: Hue API (//lights/1/state)

[ascillato2]

Hi,

Have you managed to solve your issue?

[nospam2000]

My issues are now solved. I use tasmota for shutters and therefore I need to emulate a dimmable lamp without any colors. See my branch and the checkin for shutters which emulate a dimmable lamp.

There are several problems:

1. Alexa is very picky about the consistency across the values. That means for a dimmable lamp the "on" value and the "bri" value must fit together: on==true: 6 <= bri <= 254 on==false: bri = 0 For a color lamp there are probably more dependencies especially between the different color rooms (hsv, rgb, x/y). Setting x/y to a fixed value is not a good idea, better leave it out when it is not supported.

2. When Alexa sets bri to a value, the value of bri is checked after setting it (I don't mean the response, there is an extra read call). When the value doesn't exactly match, you will get a "the device doesn't work correctly" error message. When converting between the alexa bri values and internal float percentage values, the formulas must be corrected:

   Alexa_bri = (uint8_t)(253.0f * Tasmota_bri + 1.5f))
   Tasmota_bri = (float)Alexa_bri / 253.0f

   The factor 254 was incorrect. I checked it for around 30 different bri values and the formula above (especially the first one) gives an exact result for all that percentage values.

3. The discovery should only return the values for the configured lamp type, the means the color values should not be reported for a dimmable lamp and a on/off lamp should not report bri. This is missing in my checkin, it only supports a dimmable shutter.

[ascillato]

Very interesting. Thanks.

Please, can you make a Pull Request ?

[nospam2000]

The concept of the lamp types and subtypes is still unclear to me, especially how to store separate bri value when you have multiple lamps. I have seen there is not only a bri value (mapped to 'light_brightness'), but additionally a dimming setting and I didn't understand the relationship between those two.

To make a working pull request there need to be some clarifications before. With the main branch, only one dimmable/color lamp can work. For the shutters I'm using (from stefanbode's fork) each shutter has a separate position which is mapped to a separate bri value.

[nospam2000]

@ascillato2: I now made a first version, see my emufix branch. I haven't tested it with any color lamps yet, just simple on/off lamps and in the context of shutters I tested the brightness. Can anybody please test this version with a color lamp?

[ascillato]

Hi, your modifications seems ok but I don't have Alexa to test that.

@reloxx13 Please, could you test that?

[nospam2000]

In the meanwhile I have done some tests on my own:

1. Moduletype = 22 Sonoff BN SETOPTION15 1 => the lamp shows up as dimmable lamp
2. ModuleType = 17 AiLight => the lamp is detected as multicolor dimmable lamp

[nospam2000]

After some more tests with the brightness value of the multicolor lamp it turned out, that there are so many conversions in xdrv_04_light.ino which all intruduce rounding errors. That means it is almost impossible to get the same brightness value back that you have written, at least when the RGB mapping is used ((light_subtype > LST_COLDWARM && !gotct)==true) and LightRgbToHsb() is called. I tried to fix some of the conversions and tested all percent values from 2 to 100. 64 values are working, here the test results with the list of values which give the error "Lampe1 scheint nicht richtig zu funktionieren" (in english: "Lamp1 doesn't work properly"):

setpoint%  intern%   setpointA readoutA
                     Alexa     Alexa
3                      9         8
5                     14        13
7                     19        18
9                     24        23
33         32         84        82
40                   102       103
42         41        107       105
44         43        112       110
46         45        117       115
48         47        122       120
51                   130       129
52                   133       132
53                   135       134
54                   138       137
56                   143       142
58                   148       147
60                   153       152
61         60        155       154
62                   158       157 
64                   163       162
66                   168       167
67                   171       170
68                   173       172
69                   176       175
70         69        178       177
71                   181       180
77                   196       195
79                   201       200
80                   203       204
81 ????????? => Alexa: "I don't know how to perform this setting"
82         81        208       205
91         90        231       229
93         92        236       233
95         94        241       239
97         96        246       244
99         97        251       248

The list contains only values in column 2 and 4 when the value is wrong. Column 2 should match column 1, column 4 should match column 3. A possible solution would be to store the written values in xplg_wemohue.ino and cache them for 2 seconds, so those values can be returned exactly without conversion and the read request following the write request would be satisfied.

Michael

[nospam2000]

Hi,

I now made some unit tests and added them to my git branch:

1. tools/TestAlexaValueMappings.cpp: tests the behaviour and quality of my own Alexa to factor functions
2. tools/TestColorPluginValueMappings.cpp: tests the behaviour and quality of the LightSetHsb() and LightGetHsb() functions, depending on light_type, light_subtype and Settings.module. At the moment I only test the bri value.

The results are good, except for the following settings:

    light_type = LT_RGBWC;
    light_subtype = LST_RGBWC;
    Settings.module = AILIGHT;
    bool gotct = false;

I can tune the conversion to a match rate of 70%, but not more.

This means the module type SONOFF_BN with SETOPTION15 1 works good, but not the color lamps. I made no tests for gotct=true. Either the LightSetHsb() and LightGetHsb roundtrip precision is enhanced, or the values need to be stored as duplicate in the emulation plugin.

To make it clear: all values are set correctly (+-2%), but you will get the annoying Alexa message, that the device is not working properly.

Michael

[andrethomas]

Hi, any feedback on this issue?

[ascillato2]

@nospam2000

Hi,

Any news on this?

[ascillato]

Hi,

Any news on this?

[nospam2000]

No news. I uploaded my current state to my emufix branch and nobody had the time to test it.

@yonaesp and @Boris16: can you please test my version and give feedback?

[Jason2866]

@nospam2000 Will try too the next few days. But i think i cant help much because i never had this problem! So my test will be just, is there something broken with this changes