WiFi thermostat discussion

[uzlonewolf]

I recently picked up a WiFi thermostat off Amazon, the "Wi-Fi Smart Color Thermostat, 7 Day Programmable and 4 Modes, Touch Screen Home Thermostat with Zone Remote Sensor, Smart Thermostat Compatible with Alexa and Google Assistant, 2.4GHz" by MoesHouse (ASIN B09WV347GJ). It seems to be a rebranded PCT513-TY. Searching Tuya's developer portal for both the product ID as well as the category code brings up a DPS list which isn't even close to what this thing is using. I was able to reverse engineer almost every DPS it uses however.

Some of these DPS' are returned on poll request while others are only broadcasted periodically.

'2': 'cool', # system mode [ auto cool heat off ]
'16': 2100, # setpoint C
'17': 70, # setpoint F
'23': 'f', # display units (C or F)
'24': 2050, # cur temp C
'29': 69, # cur temp F
'34': 64, # cur humidity
'45': 0, # fault flags
'107': '4', # system type: 0 = cool only, 2 = heat only, 4 = cool&heat or heatpump, 5 = heatpump with aux/emergency heat
'108': 2100, # cool setpoint C
'109': 1650, # heat setpoint C
'110': 70, # cool setpoint F
'111': 62, # heat setpoint F
'115': 'auto', # fan mode [ auto cycle on ]
'116': '1',
'118': [base64 blob], # schedule
'119': False, # schedule enabled
'120': 'permhold', # [ permhold temphold followschedule ]
'121': [base64 blob], # vacation data
'122': [base64 blob], # sensor data
'123': 25, # minimum fan run time
125-128: [base64 blob] # number of sensors
'129': 'alloff' # system state [ fanon coolfanon alloff ]

107 and 116 have not changed for me and I have no idea what they mean. Inspecting the network traffic in the developer portal says 107 is 温控系统类型 (Goog translate: "Type of temperature control system"); my system type is a 1-stage heatpump. 116 says 在家/离家 ("at home/away from home"); I have never seen this change from a "1". Of the 7 base64 binary blobs, I have not even looked at 118 or 121 (edit: 118 discussed in a post below). 125-128 base64-decode to a single byte which matches the number of sensors installed (0x01 = base only, 0x02 = base plus a remote sensor). 122 is the sensor data packet and is broadcast approx. once every 62 seconds if something has changed, otherwise it is not broadcast. The 62-second timer is per sensor, so if you have multiple sensors you will get multiple broadcasts, however even though the broadcast includes data for every sensor only the data for 1 sensor will have changed. The developer portal says 122 is 外部温度传感器信息列表1 ("External temperature sensor information list 1") and 125-128 are 外部温度传感器信息列表2 ("External temperature sensor information list 2") - 外部温度传感器信息列表5 ("External temperature sensor information list 5").

122 Broadcasts when I first installed the system without any remote sensors installed:

Received Payload: {'dps': {'122': 'AQAAXtYAAAAAAAAAAAAAAAAAAAAATXkgRGV2aWNlIG5hbWUBAAe1AQ8AAQABAAAAAAAAAAA='}, 't': 1654961732}
Received Payload: {'dps': {'125': 'AQ=='}, 't': 1654961732}
Received Payload: {'dps': {'126': 'AQ=='}, 't': 1654961732}
Received Payload: {'dps': {'127': 'AQ=='}, 't': 1654961732}
Received Payload: {'dps': {'128': 'AQ=='}, 't': 1654961732}

After installing a remote sensor:

Received Payload: {'dps': {'122': 'AgAAXtYAAAAAAAAAAAAAAAAAAAAATXkgRGV2aWNlIG5hbWUBAQfTAQ9jAQABAAAAAAAAAABSAwODAAAAAAAAAAAAAAAAU2Vuc29yXzUyMDMwMzgzIGcAAQEJcwEHRgEKAAAAAAAAAAAA'}, 't': 1655098871}
Received Payload: {'dps': {'125': 'Ag=='}, 't': 1655098871}
Received Payload: {'dps': {'126': 'Ag=='}, 't': 1655098871}
Received Payload: {'dps': {'127': 'Ag=='}, 't': 1655098871}
Received Payload: {'dps': {'128': 'Ag=='}, 't': 1655098871}

That 'AQ==' decodes to 0x01 and 'Ag==' is 0x02 so I suspect they are some sort of sensor count for something. Changing the Wake/Away/Home/Sleep sensor participation flags does not change them at all.

Base64-decoding the data and displaying it as hex results in
0200005ED6000000000000000000000000000000004D7920446576696365206E616D65010108C3010F00010001000000000000000052030383000000000000000000000000000053656E736F725F35323033303338330001010959010046010A000000000000000000

That very first 02 is the number of sensors installed in the system. The rest breaks down as:

00005ED6 000000000000000000000000000000004D7920446576696365206E616D65 01 01 08C3 01 0F 00 01 00 01 0000000000000000
52030383 000000000000000000000000000053656E736F725F353230333033383300 01 01 0959 01 00 46 01 0A 00 0000000000000000
Sens.ID#| NUL-padded name                                            |en|oc|temp|on|pa|ba|fw|u2|av|u3

Where "Sens.ID#" is the sensor ID number
"NUL-padded name" is the human-readable name displayed in the app
en - Enabled flag, 0 = Disabled, 1 = Enabled
oc - Occupied flag, 0 = Unoccupied, 1 = Occupied
temp - Temperature in degrees C multiplied by 100 (0x08C3 = 2243 = 22.43°C)
on - Online, 0 = sensor offline, 1 = sensor online. A sensor is marked offline if it hasn't been heard from in approx. 4 minutes
pa - Wake/Away/Home/Sleep Participation bitmask. 1 = Wake, 2 = Away, 4 = Home, 8 = Sleep
ba - Battery %. 0x63 = 99 = 99%, 0x46 = 70 = 70%
u2 - Unknown # 2, I have no idea what this is
fw - Firmware Version, 01 = V0.1
av - Sensor is participating in temperature averaging. 0 = not participating (either Participation bit for the current mode is 0 or it is marked Unoccupied), 1 = participating in the average (Participation bit for the current mode is 1 and it is marked Occupied)
u3 - Unknown # 3, I have no idea what this is

I'm not sure what "u2" is for. One possibility could be update rate: 0x0A = 10 = every 1.0 minutes. Not sure how I'll be able to test that though.

The name field is a bit interesting. Originally the name for sensor # 1 was left-justified, but after changing it in the app it became right-justified. Sensor # 2 was initially almost right-justified (there was a single NUL after it) but changing it in the app made it completely right-justified.

01 00005ed64d792044657669636500000000000000000000000000000000000000000001000828010f000100010000000000000000
01 00005ed6000000000000000000000000000000004d7920446576696365206e616d65010107a8010f000100010000000000000000

02 52030383000000000000000000000000000053656e736f725f35323033303338330001010907010f00010a000000000000000000
02 5203038300000000000000000000000000000053656e736f7220353230333033383301000926010e46010a000000000000000000

The remote sensor is a PIR323-915 temperature+occupancy sensor. My research leads me to believe it is Zigbee in the 915MHz band. I would like to add more to see what it does, however Zigbee temperature sensors in the 915MHz band seem to be unobtanium.

Edit: through the magic of buying 2 complete sets, I have acquired a 2nd remote sensor. It simply tacked it onto the end of DPS 122 and changed the first byte of 122 and 125-128 from a 2 to a 3. Assuming it simply keeps adding them like this, it can hold 15 sensors in a 1500-byte packet. My guess is after 15 (or some lower number) it would then start putting them into the next DPS. It turns out the sensor lists for lists 2-5 are slightly different than I expected. When there are no sensors in the list, the list contains a single byte which matches the total number of sensors. When the list does contain sensors then that first byte is removed and the list contains nothing but the sensor data. Each list contains a maximum of 4 sensors (so list 1 has a max of 209 bytes while lists 2-5 have a max of 208 bytes).

[jasonacox]

Brilliant work on this @uzlonewolf ! Thanks for posting this for the community. I would like to add this to the end of the Tuya Data Points - DPS Table section the list the basic DPS values you identified with a link to the detailed breakdown you posted above. Would you want to submit a pull request for that?

Thanks again! Great research and very helpful. And I love "unobtanium". ❤️

[uzlonewolf]

Done, #141 .

What are your thoughts on adding classes for this? There are enough quirks with setting temperatures and modes that I think it would be helpful, and managing the sensor data list without parsing it into a class would be difficult.

[jasonacox]

PR accepted! Thank you!

I'm open to adding more classes. If we do, I have two thoughts:

• I would want to structure them outside of the core to allow natural proliferation of classes without making it unwieldy, by breaking the classes into separate files, allowing for simple from tinytuya import thermostat management.
• We need clear expectations on support for these classes. Adding more increases the surface area for issues. Right now, I have devices to represent all of the classes so I can test and help with issues. If we add devices beyond that, I'll need help if there are issues or firmware updates that require changes. I'm game but would want to clearly outline expectations in the README (eg. mileage may vary). 😄

[uzlonewolf]

Yep, I hear that.

I've been hesitant to call it 'thermostat' as I have a sample size of 1 and have no idea if other manufacturers are going to use the same DPS set. I also see line-voltage thermostats available which I suspect will not use this DPS set as their feature set is completely different. Calling it 'PCT513' doesn't feel right either because there may be other thermostats which also use this DPS set. Not sure what I'm going to call it yet...

[uzlonewolf]

Initial code committed to my fork. Only handles sensors at the moment, there's a lot left to do. https://github.com/uzlonewolf/tinytuya/blob/thermostat/tinytuya/ThermostatDevice.py

[uzlonewolf]

Oh, heh, it's a happy accident then as I had simply not yet gotten around to adding it to init.py. The only thing I don't like about it is you need to call d = ThermostatDevice.ThermostatDevice() to use it. I could move it into a submodule to avoid that, but it feels wrong to have an entire submodule for a single class. I was thinking we could have a "Contrib" or "Community" submodule which would import it (and any additional non-standard devices), so it would be used like

import tinytuya
from tinytuya import Contrib
...
d = Contrib.ThermostatDevice()

Thoughts?

[uzlonewolf]

What should we do about taxonomy?

At this point I'm thinking we'll cross that bridge once we get to it. If it's a similar thermostat device we could do the A/B/C thing like the bulbs use, or if it's a different type we could add say LineThermostat for a line-voltage thermostat or HeatingThermostat or BoilerThermostat for heating-only thermostats.

[jasonacox]

I agree @uzlonewolf and I really like the submodule idea of "Contrib"! Feel free to submit a PR for the first Contrib device if you want. I'll add some notes to the documentation.

[uzlonewolf]

Cool, I'm going to bang on it a bit more and get some documentation on it written up before submitting the PR.

[jasonacox]

Thanks for the PR #146 ! You forgot to add credit for the contribution. I added a note.
f33ebed 🙏

[uzlonewolf]

Finally got around to looking at the schedule. Was pretty easy to decode, though I'm not sure if I care enough to add a class for it.

It's Bas64 encoded and in DPS 118. A packet looks something like
{'dps': {'118': 'AAE0CDQKWgEB4AZyC7gCBDgINAn2AwUoBnIKvv///4AAgAAAATQINAn2AQHgBnILuAIEOAg0CfYDBSgGcgq+////gACAAAABNAg0CfYBAeAGcgu4AgQ4CDQJ9gMFKAZyCr7///+AAIAAAAE0CDQJ9gEB4AZyC7gCBDgINAn2AwUoBnIKvv///4AAgAAAATQINAn2AQHgBnILuAIEOAg0CfYDBSgGcgq+////gACAAAABNAg0CfYBAeAGcgu4AgQ4CDQJ9gMFKAZyCr7///+AAIAAAAE0CDQJ9gEB4AZyC7gCBDgINAn2AwUoBnIKvv///4AAgAA='} }

In the above I have:
Wake: 5:08, heat to 70, cool to 78
Away: 8:00, heat to 62, cool to 86
Home: 18:00, heat to 70, cool to 78
Sleep 22:00, heat to 62, cool to 82

The first day (Sunday) has Wake set to "cool to 80" but is otherwise the same. After Base64 decoding and wrapping at 70 chars (35 bytes) you get:

00013408340a5a0101e006720bb8020438083409f603052806720abeffffff80008000 # Sunday
000134083409f60101e006720bb8020438083409f603052806720abeffffff80008000 # Monday
000134083409f60101e006720bb8020438083409f603052806720abeffffff80008000 # Tuesday
000134083409f60101e006720bb8020438083409f603052806720abeffffff80008000 # Wednsday
000134083409f60101e006720bb8020438083409f603052806720abeffffff80008000 # Thursday
000134083409f60101e006720bb8020438083409f603052806720abeffffff80008000 # Friday
000134083409f60101e006720bb8020438083409f603052806720abeffffff80008000 # Saturday

Despite there being 4 schedule slots per day, there are actually 5 in the data block. Wrapping every 14 chars (7 bytes) gives:

00 0134 0834 09f6
01 01e0 0672 0bb8
02 0438 0834 09f6
03 0528 0672 0abe
ff ffff 8000 8000

pf|time|heat|cool

Where:
pf is which participation flag to use: sensors are selected when sensor.participation & (1 << pf) is true
time is minutes since midnight: 5:08 am = (5 * 60) + 8 = 308 = 0x0134
heat is "heat to" in degrees C * 100 rounded to the nearest 50: 0x0834 = 2100 = 21.0°C = 70°F
cool is "cool to" in degrees C * 100 rounded to the nearest 50: 0x09F6 = 2550 = 25.5°C = 78°F

[jasonacox]

Thanks @uzlonewolf !

I pushed v1.6.1 to PyPI so you should be able to see your module available via pip install --upgrade tinytuya. Also, I moved the ThermostatDevice-example.py to /examples/Contrib with a note in the README to make it easier for people to find. Feel free to adjust and submit any updates!

[uzlonewolf]

Well, I was working on coding it today but hit a bit of a snag. It seems the thermostat just will not send the current schedule. So far the only time I've been able to get it to send DPS 118 is when updating it via the app or on the thermostat itself. None of updatedps(118), set_value('118', None), or generate_payload( DP_QUERY, ['118'] ) will cause it to send the current schedule. Changing the schedule might need to be a 1-way operation.

[uzlonewolf]

Through trial and error I found that what I thought was an id / index actually sets which participation flag bit to match against. If it is equal to or greater than "4" it half-disables that schedule slot - the scheduled temperature will not be changed until it advanced into the next time period. The thermostat also uses "last set takes priority" if 2 periods are set to the same time. This can be a problem as the app sets the last slot to "4" and midnight if it encounters an invalid schedule configuration - thereby disabling your ability to set midnight as a schedule period. (If something has an edge case I will find it 🤣)

[uzlonewolf]

Okay, I think I'm like 90% done, just need to bang on it for a bit and write the documentation. Hopefully I'll get a PR finished tomorrow (later today?).

[jasonacox]

Awesome! PR merged! I'll release this in the 1.6.2 build.

[uzlonewolf]

Hark, the unobtanium has been obtained! Fresh off the boat from China:

It turns out the sensor lists for lists 2-5 are slightly different than I expected. When there are no sensors in the list, the list contains a single byte which matches the total number of sensors. When the list does contain sensors then that first byte is removed and the list contains nothing but the sensor data. Also, each list contains a maximum of 4 sensors (so list 1 has a max of 209 bytes while lists 2-5 have a max of 208 bytes). I've updated my code and will be making another PR once I'm done with the schedule stuff.

{'dps': {'122': 'CREREREAAAAAAAAAAAAAAAAAR2FyZGVuIFRoZXJtb3N0YXQBAQlVAQ9kAQABAAAAAAAAAAAiIiIiAAAAAAAAAAAAAAAAAABTZW5zb3JfMjIyMjIyMjIAAQEJ5gEPMgEKAAAAAAAAAAAAMzMzMwAAAAAAAAAAAAAAAAAAU2Vuc29yXzMzMzMzMzMzAAEBCfEBDzIBCgAAAAAAAAAAAEREREQAAAAAAAAAAAAAAAAAAFNlbnNvcl80NDQ0NDQ0NAABAQofAQ9QAQoAAAAAAAAAAAA='}, 't': 1657005771}
{'dps': {'125': 'VVVVVQAAAAAAAAAAAAAAAAAAU2Vuc29yXzU1NTU1NTU1AAEBCrEADzIBCgAAAAAAAAAAAGZmZmYAAAAAAAAAAAAAAAAAAFNlbnNvcl82NjY2NjY2NgABAQmWAA8AAQoAAAAAAAAAAAB3d3d3AAAAAAAAAAAAAAAAAABTZW5zb3JfNzc3Nzc3NzcAAQEJlgAPCgEKAAAAAAAAAAAAiIiIiAAAAAAAAAAAAAAAAAAAU2Vuc29yXzg4ODg4ODg4AAEBCXQADwABCgAAAAAAAAAAAA=='}, 't': 1657005771}
{'dps': {'126': 'mZmZmQAAAAAAAAAAAAAAAAAAU2Vuc29yXzk5OTk5OTk5AAEBCYoBDwABCgAAAAAAAAAAAA=='}, 't': 1657005771}
{'dps': {'127': 'CQ=='}, 't': 1657005771}
{'dps': {'128': 'CQ=='}, 't': 1657005771}

[uzlonewolf]

Another day, another quirk discovered. It turns out that even if the schedule is completely disabled, it is still followed to control how sensor averaging is done.

During the 'Sleep' period, the occupancy detectors are ignored and all enabled sensors are averaged.
During the 'Wake' and 'Home' periods, only enabled sensors detecting occupancy are used. If none of them are occupied then only the thermostat base is used even if said base is both disabled and has its participation flags unchecked.
During the 'Away' period, only enabled sensors detecting occupancy are used. If none of them are occupied then all enabled sensors are averaged.

[jasonacox]

Fascinating. At a minimum it is expect a Sleep and Wake period? And if you don't add one, does it use a default?

[uzlonewolf]

Out of the box all 4 periods are set to default times/values and neither the app nor the thermostat will allow you to delete or disable periods. You can however set multiple periods to have the same time, in which case the one later / lower down the list will take priority. I.e. if all 4 periods are set to 8:00 then 'Sleep' will be used 24/7. If 'Wake' and 'Away' are set to the same time and 'Home' and 'Sleep' are set to the same time then only 'Away' and 'Sleep' will be used. The list goes Wake->Away->Home->Sleep.

[lbendlin]

I got a homenex wi-fi thermostat from Amazon - seems to be the same device. It also reports a DPS 101 - anyone knows what that may be?
Device status: {'dps': {'2': 'auto', '16': 2000, '17': 68, '23': 'f', '24': 2350, '29': 74, '34': 50, '101': False, '107': '4', '108': 2350, '109': 1650, '110': 74, '111': 62, '115': 'auto', '116': '1', '119': True, '120': 'followschedule', '123': 15, '129': 'alloff'}}

[lbendlin]

runs on rtl8720cf_ameba chipset.

would you mind pointing me to where I can read about the browser dev console trick? Standard chromium network monitoring tools?

[uzlonewolf]

Yep, Chromium Dev Tools, Network tab. The original write-up is at https://www.zigbee2mqtt.io/advanced/support-new-devices/03_find_tuya_data_points.html#_9-find-your-data-point and in my last post I linked to my tweak to those directions which lets you see all the DPS values at once #134 (comment)

[uzlonewolf]

Oh, and mine has a WBR3 Tuya WiFi module with a DWIN T5L HMI running the show. All the interesting pins on the WBR3 have been broken out onto an (unpopulated) header making it easy to tap into. I have a boatload of hi-res pictures but haven't gotten around to uploading them.

[lbendlin]

104: Comfort presets
103: Geofencing is enforced
130: Heating runtime
131: Cooling runtime
132: Fan runtime

No trace of 101 though

[lbendlin]

Found it. 101 is Auto Following.

[uzlonewolf]

And some more quirks. As of right now I cannot recommend using these thermostats with a heat pump. A traditional furnace + A/C system is fine, however with heat pumps it de-energizes the O/B wire much too quickly thereby causing the reversing valve to cycle under pressure every time it satisfies. This might actually be fine, however I am concerned with excessive/premature reversing valve wear. I plan on talking with the manufacturer about this to see if they will change this behavior, but I have not gotten around to it yet.

The other quirk is it really, really does not like receiving setpoint and system mode changes too close to each other. If you set them both in the same packet or separate but back-to-back packets, it will tell you the setpoint has been updated but will not actually use the updated setpoint. I've had to change my code so it sends the new setpoint, receives until it gets a timeout, and then sends the system mode update. Fun times.

[lbendlin]

I noticed that it also behaves differently than my last thermostat (CT50e) in that after the completion of the cooling or heating request the fan stops immediately. With the old thermostat the fan kept running for a couple more minutes. I haven't found a way to influence that (apart from writing a monitor that would switch the fan one when heat or cool is provided and switches it off x minutes after the call is complete).

[uzlonewolf]

Stopping immediately is actually better in humid environments and will help lower humidity. Though if humidity is not a concern then running a couple extra minutes will be better for efficiency.

I thought mine did run the fan for a few minutes after the cycle, however I may be mistaken. I do use the fan circulate mode though and it might be part of that.

[lbendlin]

Humidity is not a major concern. Efficiency is. I tried the circulate mode but it is rather annoying. Instead of one 15 minute block per hour it runs three five minute blocks within the hour. Not sure what they were thinking.

[uzlonewolf]

They just pushed a firmware update, the main MCU firmware was updated from 1.5.6 to 1.5.7. The message just said "bug fixes." So far the only change I have noticed is with the sensor data - the "temp" field is now in 0.5 degree increments to match the setpoints and the first 2 bytes of the "unk3" field is the full-resolution (0.01 degree) temperature.

[uzlonewolf]

I finally got around to "listening in" on a firmware update. I tapped into the TX/RX between the WBR3 WiFi module and the DWIN T5L2 MCU and was able to dump the firmware update file. Looking at it in a hex editor showed it to be a plain unencrypted 8051 binary executable. I ran it through a couple disassemblers and the output is attached; the binary is almost 65 KiB and I just don't have the time to really dig into it. I may look at patching a couple things later though.
thermo-fw-update-2.5.7.bin.zip
thermo-fw-update-2.5.7.d52.txt
thermo-fw-update-2.5.7.mame-unidasm.txt
Edit: Oops, I named the files wrong, 2.5.7 is supposed to be 1.5.7

[Vauhkonen]

Hi! I bought also WiFi thermostat for electrical floor heating (TGR85WII-EP, Beok) and it looks like it has different DPS.

Here are my findings

Device status: {'dps':
{'1': False,
'2': 180, Set temperature (1 celcisius = 10)
'3': 198, Current temperature (1 celcisius = 10)
'4': 'cold', (status cold, hot)
'5': '0', ?
'8': False, (Child lock on / off)
'13': True, (Sound on / off)
'16': 0, ?
'20': -20, Temperature Calibration (1 celcius = 10)
'21': 25, Max setting temperature (celcius)
'25': '3', Sensor selection (1 = internal sensor, 2 = external sensor, 3 = both)
'26': False, Frost Protection (on / off)
'31': False,
'41': '1', Backlight Brightness (0 = Close, 1 = Low, 2 = Medium, 3 = High)
'42': '1', ?
'101': False, (Output main reverse on / off)
'105': 10, Temperature control switch difference (1 celcius = 10)
'107': 35} External sensor temperature limit (celcius)
}

I haven't checked any broadcast traffic, but this is just for sharing information.

[martin3000]

Any idea where I can buy the PIR323-915 ?
Maybe the 915 MHz is LoRa?

[uzlonewolf]

How many do you need? If it's only 1 I can just send it to you. If you need more then I got them from https://www.owon-smart.com/contact-us/ and were $10 each plus shipping with some other stuff.

[uzlonewolf]

As for the protocol, I doubt it's LoRa. Some documentation said it was Zigbee but I'm not sure I believe that either. The thermostat base uses a AMICCOM A7139 generic FSK transceiver chip, and the sensors use the A9108 combo 8051+transceiver.

[martin3000]

How many do you need? If it's only 1 I can just send it to you.

I would be happy with one. Of course I will pay for it. I have got the pct513, but the pir323 now fails to pair. It blinks slowly, after pressing reset it blinks a few seconds fast and then again blinks slowly. It does no longer pair with the pct513.

[uzlonewolf]

I'm not worried about $10. How about you send me yours, exchanging them? Email me your address and I'll get one out to you. lonewolf at greyskydesigns dot com.

[martin3000]

Sure we can exchange them. I am not sure if mine is ok or not, it could also be the pct513. I live in germany, and you?

[martin3000]

Today, Tuya had a firmware update for the pct513 and guess what!? The secondary sensor is working again!

[uzlonewolf]

Ugh, sorry about the late response, I thought I responded weeks ago :( I'm in the U.S. and international shipping is expensive.

I wonder if it was the firmware update or the subsequent reboot of the PCT513 which fixed it.

What version did they just push out to you? Over here they pushed 1.6.1 a few months ago and it's not showing me anything newer.

[martin3000]

Yes its 1.6.1 too.