This object is in archive! 

Firmware Version 1.3.59

Guest shared this question 5 years ago
Answered

Yesterday Zipato released version 1.3.59 as a stable release. Please share your experiences positive and negative with this release? What Zipato device you are running e.g. the Zipatile, Zipamicro or Zipabox?

The only official thing Zipato should solved are issues with the weather station not updating anymore. This caused issues with rules that are depending on this function e.g. sunset and sunrise information.

Best Answer
photo

Version 1.3.60 is available now.

Replies (13)

photo
1

All my uid for virtual devices are down because they change them !

photo
2

These are the official release notes for version 1.3.59

Fixes:

  • General: added local API for /v2/systems and /v2/abilities
  • General: report activeRoles of user on /v2/users/current locally
  • General: added wifi scan and 3G network monitor
  • General: check network online state before polling device
  • General: fix for excessive reconnects when using TCP protocol
  • General: disconnect heartbeat connection after redirect to another server
  • General: added option to disable local API
  • General: added compressed protocol
  • General: added attribute filter
  • General: faster start of mobile backup, force updating main server address(es)
  • General: added support for 1.3 slaves in master/slave systems
  • General: added option to disable server certificate validation for HTTP requests
  • General: added RGBWW attribute
  • Weather: made weather device go (on|off)line if there is (no) data
  • Weather: added direct Weather API support
  • Weather: added Yahoo Weather
  • Weather: adder Gismeteo
  • Weather: added yr.no
  • Weather: added OpenWeatherMap
  • Weather: added SunriseSunset calculator
  • Alarm: process device status updates
  • Alarm: added passthrough PIN support for non-native partitions
  • Thermostat: moved setmode logic from thermostat to actuator, not sending duplicate set mode commmands
  • Thermostat: tracking the endpoint that caused a setpoint change to prevent multiple updates
  • Zipabox2: fix for zipabox going on backup after switching from (eth+wifi) to (wifi)
  • Z-Wave: do not use SUPERVISION cc by default
  • Z-Wave: do not set started flag before network startup is done
  • Z-Wave: report fail on inclusion if saving to cloud failed
  • Z-Wave: better check for controller association when doing network heal
  • Z-Wave: compare effective values for Thermostat Setpoint
  • Z-Wave: association fixes, better handling of controller virtual endpoint
  • Z-Wave: updated manufacturer list
  • Z-Wave: poll FLIRS devices once per day by default
  • Z-Wave: added discovery command to add&delete random number of virtual slave nodes to randomize node ids
  • Z-Wave: don't make S0 and S2 devices go online after receiving ACK or NIF, crypto keys could be wrong
  • Z-Wave: S2 inclusion
  • Z-Wave: fixed S0 over S2
  • Z-Wave: create S0 & S2 keys on init & hardReset instead of on networkStartup
  • Z-Wave: always use the system temperature scale for multilevel sensors
  • Z-Wave: added FGR222 support
  • Z-Wave: use bytesize if present when sending configuration
  • Z-Wave: added support for Contec DAVINCI_WALL_CONTROLLER
  • Z-Wave: send duration=0xff by default for Multilevel Switch
  • Z-Wave: shrunk JSON configuration for User Code Input
  • Z-Wave: saving device serial, added zwDumpInfo command
  • Z-Wave: correctly handling THERMOSTAT_SETPOINT_SUPPORTED_REPORT
  • Zigbee: support for Philips Hue Dimmer Switch
  • Zigbee: added support for Sinope devices
  • Zigbee: added Hue white ambiance support
  • Zigbee: support for OSRAM devices
  • Modbus: fix for discovery fail if no IP connection
  • Modbus: support for WebRelay X-410-E Modbus device
  • Modbus: correction regarding poll timeouts
  • Modbus: additional changes to error response handling, txId mismatch and connection loss
  • Risco: correction regarding polling and tracing
  • Risco: changed Risco Discovery procedure, zones do not need to be ordered when adding
  • Lutron: fix formultiple bridges on the same Zipabox
  • Enocean: support for A51409
  • Enocean: support for D21430
  • Enocean: added battery level info to D21430
  • Lutron: corrections for discovery, incomming msg handling and online status
  • Lutron: correction for on-off switching of dimmers
  • Knx: support BAOS830
  • Camera: mangle url
  • DSC: linked DSC users with BoxUsers
  • DSC: various fixes for connecting to DSC through IP gateways
  • DSC: always update sensors, handle emergency, fire, panic
  • MQTT: create UUID on command event if it's null
  • SIA: survive CSR sending lines terminated with 0x0d 0x00
  • SIA: survive CSR sending ACK without #acct

photo
1

Has someone else trouble with the rule generator? I can't create new rules because when I pull a device into a sensor puzzle I get this result (I had tried with firefox and internet explorer)


ceeaeaaaa9b6b8506832fcc9847c7dd9

photo
1

Hi !!


My Zipamicro not install this firmware !!!

photo
1

Hi there,

just installed the new FW....everything looks fine!

regards Helle

photo
1

Zipato will probably release version 1.3.60 soon. As mentioned in a post from Zipato admin:

https://community.zipato.com/topic/weather-station-doesnt-work_1#comment-81095

I will wait for this release to launch and how stable it is.

photo
1

So does the new firmware change all the UIDs?

photo
1

Yes unfortunately. They changed the syntax from 1 uuid and value1-20= into 20 uuid's and value=. Just look it up in your virtual devices. For now the old situation works. But not sure for how long.

photo
1

Arghh. This sounds like the kind of time-wasting exercise I can do without.

photo
1

Wait, I think the UUIDs I'm using now already match the new pattern you mentioned. Is this is V2 API (https://my.zipato.com/zipato-web/v2)?


Maybe the people who've had their external code stop working are using an older API...? In the API I'm using, each meter attribute has a separate UUID, and you access the value like this:


https://my.zipato.com/zipato-web/v2/attributes/[UUID]/value

photo
1

Hi,


I use the url what i see in the device manager:

https://my.zipato.com/zipato-web/remoting/attribute/set?serial=#serial&apiKey=#apikey&uuid=#uid&value=

In the old situation (before the latest changes) you had 1 uuid and value1-20. Now you see 20 uuid's and 1 value.

At this moment i am figuring out what to do with the virtual stuff. I have some devices reporting to 4 meters (temp, hum, volt, txpower). They do that in 1 https call: with uuid=&value1=&value2= etc. I don't like to do that in 4 https calls because of the batteries.

photo
1

Ahh, we're talking about different things. Ok, that's the URL to set a value in a meter. That change is a huge PITA because it means that you have to execute 16 fetches to set 16 values, instead of just one, correct?


I was talking about the URL to obtain the value of a meter attribute, which perhaps has not changed.

photo
1

I have Google App Scripts that make frequent updates to many meters during the day. That amounts to maybe a couple of thousand HTTP calls in total. If I have to multiply that number by sixteen, I'm going to rapidly blow past the 20,000 daily URL fetch limit. Not to mention the enormous increase in the running time of the scripts, which is liable to break yet another GaS limit.

photo
1

Well OK. For the time being i have designed a solution for the battery operated devices here I am going to make a small broker with an ESP8266 (Wemos mini light or so). The battery device makes 1 https-call to this broker which will split up the call into Zipato calls. As a side effect this solution makes me a bit more independ from Zipato.

photo
1

I wonder if they are really removing the old UUIDs, or it's just a bug in the new firmware. Because prior to the new firmware (my situation), I can access the attributes collectively, with a single UUID for the meter + value1, value2... and also individually, with a UUID for each attribute.

photo
1

I don't think it has something to do with the firmware. In another post i read that someone with an old firmware had the same problem. Maybe a bug in the cloud software. I don't know. I just noticed that when you generate a new virtual meter you dont see the old value1..n anymore but only value= thing. In that case it will be hard to figure out what meter has what value. I just hope that Zipato will improve their communication. Nowadays its guessing and guessing..

photo
2

Yes, that's the main problem. Communication is terrible, and actually getting worse. For example, there used to be details about firmware updates (maintained patchily) in the Messages section, but now there's nothing. There is also less engagement in the forum, I think.

photo
1

There was an announcement, but only be found in the API (Firmware: GET. But that was for 1.3.59, to be found somewhere as a post in this forum. For 1.3.60 there's nothing.

photo
1

That says it all. You have to make an API call to find out what's in the new firmware.

photo
photo
2

After Update to 1.3.60 i can't control any z-wave devices and the box didn't sync

photo
1

After updating to FW 1.3.59 no device could be controlled and also all rules did not work anymore. After hard reset and update to 1.3.60 nothing changed. Also the synchronization of rules does not work. Ticket opened

photo
1

Same Here....

photo
1

Have you solved your problem?

photo
1

Same here have you some news?

photo
photo
1

After updating the FW to 1.3.59 my Virtual Weather Station's don't work anymore.. Hopefully they'll be back in 1.3.60

photo
1

Version 1.3.60 is available now.

photo
1

Version 1.3.60 has been mentioned in the Knowledge Base. Now there is a version 1.3.61 but not release note, no announcement...

photo
1

It hasn't been released yet.

run 3

Leave a Comment
 
Attach a file