profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/davidjb/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
David Beitey davidjb @jcu-eresearch Queensland, Australia https://davidjb.com Passionate about all things tech, particularly web, Python, Linux, other open technologies & contributing to open source software.

davidjb/buildout-vim 2

Loose collection of Buildout and Vim integration.

davidjb/autoflashgui 1

Utility to flash firmware to modems and run setup commands after the flash has completed

davidjb/bootstrap4-cheatsheet 1

Fork of the beautiful Bootstrap Cheatsheet at http://hackerthemes.com/bootstrap-cheatsheet

davidjb/.github 0

Default Community Health Files for GitHub Repos

davidjb/2016-devnq-open-source-talk 0

The HTML Presentation Framework

davidjb/2018-dark-patterns-talk 0

Presentation for DesignNQ in 2018

davidjb/2019-devnq-devs-alive 0

What can a drowning prevention campaign teach us about IT security? This talk answers this age-old question.

davidjb/2020-open-source-hacktoberfest-talk 0

Talk given on 1 October 2020 about open source software and Hacktoberfest

issue openedKoenkk/zigbee2mqtt

Philips Hue Tap Switches (Green Power) stop working after a while & need `Permit Join` or two presses

<!-- Before submitting an issue make sure you've searched for a similar issue and read the documentation: https://www.zigbee2mqtt.io/.

Rules (don't ignore these, your issue will be closed without further notice):

  • English only
  • Make sure you are on the latest Zigbee2MQTT version
  • Provide a clear description of the problem
  • DON'T copy logs directly here, post a link to https://hastebin.com/ or https://pastebin.com/.
  • Make sure you are running the latest firmware https://github.com/koenkk/z-stack-firmware.

Did you read the FAQ?

  • https://www.zigbee2mqtt.io/information/FAQ.html

Zigbee2MQTT fails to start?

  • https://www.zigbee2mqtt.io/information/FAQ.html#help-zigbee2mqtt-fails-to-start

Having issues when using a CC2531?

  • Make sure the CC2531 is connected through a USB extension cable
  • Try the source routing firmware: https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_Home_1.2/bin/source_routing
  • With larger networks (30/40+) devices, your CC2531 might not be powerful enough. This will cause weird issues, in this case it's advised to use a more powerful adapter: https://www.zigbee2mqtt.io/information/supported_adapters.html#texas-instruments-cc26x2r1

Unsupported device?

  • https://www.zigbee2mqtt.io/how_tos/how_to_support_new_devices.html

Device does not pair or interview fails?

  • https://www.zigbee2mqtt.io/information/FAQ.html#why-does-my-device-not-or-fail-to-pair

Bug report?

  • If applicable, provide steps how to reproduce the problem.
  • Provide the herdsman debug logging: https://www.zigbee2mqtt.io/information/debug.html#zigbee-herdsman-debug-logging

-->

<!--Start your bug report below this line-->

What happened

I have a number of Philips Hue Tap switches paired and on my network, as well as Hue bulbs in range of all switches to do the translation. Everything works fine but after a while, a given switch will no longer function. This presents in two different ways:

  1. Once a switch has been unused for a certain amount of time, it ceases to function on the network even though it is still paired. I've observed that switches last used less than 2 hours ago are fine but ones that were last used 6 hours ago or more aren't.

    • To workaround: toggle Permit Join to be on, then press any button on one of the problematic switches. This press will be received by z2m and work. At this point, you can disable join for the network. Curiously, after this point, all of the other problematic switches will now immediately work once an unrelated switch has been pressed when zigbee was joinable.
    • This is not an issue with range or signal; a switch right next to the coordinator that was last used a day or a week ago doesn't work but a switch with a low LQI (out on the edges of the network) - that was used in the last hour - still continues to work when the others don't.
    • It appears it's a matter of timing - somewhere between 2 and 6 hours, switches appear to get "disconnected" or forgotten, requiring the workaround to keep using the switches.
    • When a switch has become disconnected/forgotten, pressing the switch shows no debug messages in the logs, implying messages aren't being received. Repeatedly pressing the switch does nothing
  2. A press of a switch takes place but no message is received through to z2m. A subsequent press of the same switch immediately after is received through to z2m and the switch is now back to being functional.

    • Other switches continue to operate fine under this circumstance. In other words, this issue appears isolated to that switch.
    • Note that because of the erratic and unpredictable behaviour, I haven't yet been able to narrow down logs or specific circumstances that lead to this problem. I expect for the first press, no logging will be shown in z2m though (e.g. message entirely unreceived)
    • Could this be perhaps symptomatic of needing the first press to "wake up" or establish a route?

I've previously used various older versions of z2m (and Zigbee firmware) and have noticed the 2nd issue on occasion but never encountered the first issue until what appears to be 1.21.x. Unfortunately, I need specific device support provided in 1.21.1 so rolling back my main network isn't feasible, but I could test up a test environment with a separate network if need be.

What did you expect to happen

Switches to continue functioning regardless of time since last press & on first press.

How to reproduce it (minimal and precise)

Debug info

Zigbee2MQTT version: 1.21.1 Adapter hardware: CC2652R / zzh Adapter firmware version: 20210708

created time in a day

pull request commentgithub/docs

Clarify nature of GITHUB_ENV/GITHUB_PATH variables

@ramyaparimi the checkbox was already enabled so hopefully that’s good to go. Otherwise, I can take a look tomorrow and rebase the changes.

davidjb

comment created time in 3 days

push eventdavidjb/user-scripts

David Beitey

commit sha c3f8e34cedd06ef286198a1adba30463f36cbdb3

feat: add links back to live/production; minor button reorganisation

view details

push time in 4 days

push eventdavidjb/user-scripts

David Beitey

commit sha 3b6b962381be758f93d908db05bc0e8a13324146

fix: make RDJ script domain agnostic

view details

push time in 4 days

delete branch jcu-eresearch/shared-salt-states

delete branch : cookbook-update

delete time in 4 days

push eventjcu-eresearch/shared-salt-states

ElizabethForest

commit sha 21b5e8779a70f40861feec62b98dc297391080f5

update to use cookbook

view details

David Beitey

commit sha df519ecbe01f441fb817032f2872693b97c2a38a

Merge pull request #3 from jcu-eresearch/cookbook-update update to use cookbook

view details

push time in 4 days

PR merged jcu-eresearch/shared-salt-states

update to use cookbook

The changes were very minor, since the pages are very simple. I just updated some of the class names and I used a dark alert since there isn't a jumbotron class in cookbook v3.2.

Before: image

After: image

+27 -18

0 comment

3 changed files

ElizabethForest

pr closed time in 4 days

PullRequestReviewEvent

PR opened redbox-mint/redbox-portal

Allow Sails session adapter (connect-mongo / mongodb) to reconnect without requiring restart

This fixes the Error occurred in session middleware :: 'MongoError: Topology was destroyed errors that occur when a Sails session is attempted to be created when the underlying Mongo connection has been interrupted (e.g. if Mongo is offline or had previously been offline or restarted; its connection affected).

Previously, this type of problem required a restart of the ReDBox application because the MongoDB topology/connection couldn't automatically recover from its DESTROYED state. This PR allows automatic recovery to occur during an incoming request if MongoDB becomes available before the topology timeout elapses (or on subsequent requests once Mongo is available again).

This PR upgrades connect-mongo to its latest release version (v4.6.0) in order to update the underlying mongodb package enabling better topology management and automatic reconnection. To enable the latest connect-mongo to be used, this PR upgrades Sails to v1.5.0 in order to gain support for this the newest versions of this package. Additionally, since connect-mongo v4.6.0 now has mongodb as a peer dependency, this PR adds mongodb as a dependency to redbox-portal. This latest version of mongodb bumps the node requirement to >=12.9.0 (and connect-mongo requires >=12) but the existing Docker container environment has v12.16.0 available.


The original issue was at ReDBox became unavailable when attempting to load any page invoking the session machinery (e.g. http://localhost:1500/default/rdmp/home) at a time after after MongoDB's connection was interrupted. On the first request, a ReDBox page would load and display, but an internal session error was logged:

 warn: The session middleware encountered an error and triggered its callback, but response headers have already been sent.  Rather than attempting to send another response, failing silently...

This had the effect of setting sails.sid into the user's browser, meaning that a session get() took place earlier in the call stack, leading to the following traceback being displayed in the user's browser:

Error occurred in session middleware :: 'MongoError: Topology was destroyed\n' +
  '    at nextFunction (/opt/redbox-portal/node_modules/mongodb-core/lib/cursor.js:547:27)\n' +
  '    at Cursor.next [as _next] (/opt/redbox-portal/node_modules/mongodb-core/lib/cursor.js:701:3)\n' +
  '    at nextObject (/opt/redbox-portal/node_modules/mongodb/lib/cursor.js:680:8)\n' +
  '    at Cursor.next (/opt/redbox-portal/node_modules/mongodb/lib/cursor.js:270:12)\n' +
  '    at findOne (/opt/redbox-portal/node_modules/mongodb/lib/collection.js:1414:10)\n' +
  '    at /opt/redbox-portal/node_modules/mongodb/lib/collection.js:1404:5\n' +
  '    at new Promise (<anonymous>)\n' +
  '    at Collection.findOne (/opt/redbox-portal/node_modules/mongodb/lib/collection.js:1403:10)\n' +
  '    at /opt/redbox-portal/node_modules/connect-mongo/src/index.js:193:40\n' +
  '    at runMicrotasks (<anonymous>)\n' +
  '    at processTicksAndRejections (internal/process/task_queues.js:97:5)'

(removing the sails.sid cookie would allow one request to succeed, erroring silently, whilst setting another sails.sid cookie)

With this PR in place, it's worth noting that users can still experience raw tracebacks as follows, so it'd be worth looking at how to hide these sorts of tracebacks from production. This situation only persists until MongoDB becomes available again; this traceback is only dumped out when the topology timeout elapses, such as when MongoDB is offline:

Error occurred in session middleware :: 'MongoServerSelectionError: getaddrinfo ENOTFOUND mongodb\n' +
  '    at Timeout._onTimeout (/opt/redbox-portal/node_modules/mongodb/lib/sdam/topology.js:325:38)\n' +
  '    at listOnTimeout (internal/timers.js:549:17)\n' +
  '    at processTimers (internal/timers.js:492:7)'
+177 -92

0 comment

3 changed files

pr created time in 6 days

push eventdavidjb/redbox-portal

David Beitey

commit sha a738d8c302f7088381c6a84eff7ccff4e2611c78

Allow Sails session adapter (mongo) to reconnect This fixes the `Error occurred in session middleware :: 'MongoError: Topology was destroyed` errors that occur when a Sails session is attempted to be created when the underlying Mongo connection has been interrupted (e.g. if Mongo is offline or had previously been offline or restarted, and its connection affected). Previously, this type of crash required a restart of the ReDBox application because the topology/connection couldn't automatically recover from its `DESTROYED` state. This PR allows automatic recovery to occur on subsequent incoming requests (or on a given request, if MongoDB is available again before the topology timeout elapses). For note, if this timeout does elapse, such as if or when MongoDB is offline, users will still see a network-related traceback, but this only persists until MongoDB becomes available again. This PR upgrades `connect-mongo` to its latest release version (v4.6.0) in order to update the underlying `mongodb` package enabling better topology management and automatic reconnection to mongo. To enable the latest `connect-mongo` to be used, this PR upgrades Sails to v1.5.0 in order to gain support for this newer package. Additionally, since `connect-mongo` now sets `mongodb` as a peer dependency, this PR adds `mongodb` as a dependency to `redbox-portal`.

view details

push time in 6 days

create barnchdavidjb/redbox-portal

branch : fix-topology-destroyed-crash

created branch time in 6 days

delete branch davidjb/redbox-portal

delete branch : fix-topology-destroyed-session-crashes

delete time in 6 days

create barnchdavidjb/redbox-portal

branch : fix-topology-destroyed-session-crashes

created branch time in 6 days

issue commentKoenkk/zigbee2mqtt

Philips Hue bulb firmware OTA update "successful" but firmware is still the old one

@liuk4friends Excellent, glad you've got a working z2m. The previous commit in zigbee-OTA has the older Philips Hue firmware you're looking for, which is the instructions mentioned in my comment above. If you've edited zigbeeOTA.js, make sure you restart z2m so the change get picked up. If you're still having issues, try enabling debug logging and look through what's occurring with the OTA process - hopefully that reveals what's happening.

LeoCal

comment created time in 6 days

issue commentKoenkk/zigbee2mqtt

Philips Hue bulb firmware OTA update "successful" but firmware is still the old one

@liuk4friends installing an older version is a case of switching versions in git. In the installation instructions, just before you run npm ci checkout a specific release tag with git checkout 1.20.0 where the latter argument is a version number that you know works or want to try (from https://github.com/Koenkk/zigbee2mqtt/releases). If you need to switch versions later, then checkout another version and re-run npm ci to correctly install the dependencies for that version

LeoCal

comment created time in 6 days

issue commentKoenkk/zigbee2mqtt

Philips Hue bulb firmware OTA update "successful" but firmware is still the old one

No worries @liuk4friends. Fwiw, installing z2m locally on a Mac directly is possible (e.g. without Docker); you can install and run with npm and brew install mosquitto to get an MQTT broker set up.

Otherwise, if you’ve got/get a spare MicroSD card for your Pi, you could flash Raspian and use that as a temporary environment, using the official instructions from https://www.zigbee2mqtt.io/getting_started/running_zigbee2mqtt.html to directly install.

LeoCal

comment created time in 6 days

push eventdavidjb/user-scripts

David Beitey

commit sha 21252f8d509b6a22dd0d6c6fa5ece88fa098223e

Apply RDJCU user scripts to internal environments

view details

push time in 7 days

startedau-research/datacite-api-notebook

started time in 7 days

issue commentKoenkk/zigbee2mqtt

Philips Hue bulb firmware OTA update "successful" but firmware is still the old one

@liuk4friends I imagine you're using https://github.com/zigbee2mqtt/hassio-zigbee2mqtt as an add-on in Home Assistant, which means your z2m installation is inside a Docker container. This makes things interesting since Docker containers' files are designed to be immutable (with the exception of config files on volumes). I don't use this environment myself but I see you having two options:

  • Directly on your Pi; modified Docker container:

    1. Stop the z2m add-on container (in the HA UI or via SSH)
    2. Run a new version of this add-on's container and console into it (e.g. docker run -it name-of-container bash)
    3. Make the changes to zigbeeOTA.js (z2m appears to be installed in /app given the Dockerfile); you'll probably to have to install vi or another editor in the container
    4. Inside the container, run npm start in /app to boot z2m.
    5. While this is running, perform your OTA update
    6. When done, exit the container (this kills it) and start up your add-on again
  • Create a second temporary Zigbee network; on a second computer or device:

    1. Install z2m + an MQTT broker like mosquitto on a second computer
    2. Borrow your zigbee dongle from your Pi and plug it in
    3. Configure z2m accordingly (with separate network details to your primary network)
    4. Make the URL changes to zigbeeOTA.js
    5. Start z2m, join your bulbs to this temporary network and do the first OTA upgrade
    6. Stop z2m, revert changes to zigbeeOTA.js
    7. Start z2m again, do the 2nd OTA upgrade
    8. Stop z2m - keep this install around if you want to upgrade more bulbs later
    9. Reattach your dongle to your Pi, restart the z2m HA Add-on and re-join your bulbs into your primary network

Hope that helps.

LeoCal

comment created time in 7 days

issue commentKoenkk/zigbee2mqtt

Philips Hue bulb firmware OTA update "successful" but firmware is still the old one

@LeoCal Because of how zigbee-herdsman-converters works, you can easily point your install of zigbee2mqtt at an older version of the complete firmware library. In short, change this line (https://github.com/Koenkk/zigbee-herdsman-converters/blob/master/lib/ota/zigbeeOTA.js#L1):

const url = 'https://raw.githubusercontent.com/Koenkk/zigbee-OTA/master/index.json';

to point to an older commit of zigbee-OTA. For me, I just picked the previous commit, before the Hue firmwares were modified, meaning the first line of zigbee-herdsman-converters's zigbeeOTA.js temporarily becomes:

const url = 'https://raw.githubusercontent.com/Koenkk/zigbee-OTA/4af6b2a99517f57c0111566a9735b40ecdbc2af7/index.json';

At that point, restart zigbee2mqtt and you'll be now upgrading all Philips Hue firmwares to their next-to-last versions. When done, restore zigbeeOTA.js to its original state and restart zigbee2mqtt again. Down the road, the history of index.json shows you the commits available in case further gymnastics are needed between firmware versions or with specific devices.

Enabling debug logging is a good idea too - it helps monitor internal details and progress during the upgrade & you can confirm the right version of zigbee-OTA is being used by the specs of firmware being downloaded.

LeoCal

comment created time in 9 days

issue commentKoenkk/zigbee2mqtt

Philips Hue bulb firmware OTA update "successful" but firmware is still the old one

Experiencing the same issue with the same firmware version; model for me is https://www.zigbee2mqtt.io/devices/9290012573A.html#philips-9290012573a. I've confirmed the newer firmware is successfully downloaded and verified, then OTA happens like @LeoCal describes but z2m reports that the firmware was "upgraded" from the current version to the same version.

I'm wondering if this might be similar to #8719 in terms of a solution - will try upgrading via the previous firmware since that worked for me previously on other Hue models.

LeoCal

comment created time in 11 days

push eventjcu-eresearch/undo.jcu.io

David Beitey

commit sha 68b859edacb3649781b3c119ed572dcb6aa0dafe

Update JCU CookBook; use SRI tags

view details

push time in 12 days

created tagjcu/cookbook

tagv3.2.2

The HTML, CSS, and JavaScript framework for James Cook University web applications and projects.

created time in 13 days

push eventjcu/cookbook

David Beitey

commit sha e83ea10a34210a8bdb31f23ce6b0ca132272107f

chore: tidy

view details

David Beitey

commit sha cf33b435c3cdd129d9990560a744481986c96e4e

fix: downgrade imagemin to fix SoTT svg

view details

David Beitey

commit sha 46fcd28e38a6080cc5cfb246dda954a665a5a3a9

chore: release v3.2.2

view details

David Beitey

commit sha 59e19e7bc299fbe620455a190700c87c31b90cfc

chore: back to development

view details

push time in 13 days

push eventdavidjb/cv

David Beitey

commit sha 94953b4302f4a1669ea071ddcda5e7bb073109f1

Update CI to Node 16.x

view details

push time in 14 days

push eventdavidjb/cv

David Beitey

commit sha 72991917fa8702a67d39e5eca500c245f712291d

Add memberships to CV

view details

push time in 14 days

created tagjcu/cookbook

tagv3.2.1

The HTML, CSS, and JavaScript framework for James Cook University web applications and projects.

created time in 15 days

push eventjcu/cookbook

David Beitey

commit sha 129625e7856cb8165468c297866996f34eecdb3a

fix: move runtime deps, remove unused deps

view details

David Beitey

commit sha 609aca75500d3e7afcb3b13d7f9be862d1d5731d

docs: rebuild

view details

David Beitey

commit sha 2decca312b3b0a9bf96749647472784a6a169237

Release v3.2.1

view details

David Beitey

commit sha ad615b1a65c740c211533cef885791fa3ef50978

Back to development

view details

push time in 15 days

issue openedKoenkk/zigbee2mqtt

`Invalid image` when upgrading factory Philips Hue White Ambiance bulbs

<!-- Before submitting an issue make sure you've searched for a similar issue and read the documentation: https://www.zigbee2mqtt.io/.

Rules (don't ignore these, your issue will be closed without further notice):

  • English only
  • Make sure you are on the latest Zigbee2MQTT version
  • Provide a clear description of the problem
  • DON'T copy logs directly here, post a link to https://hastebin.com/ or https://pastebin.com/.
  • Make sure you are running the latest firmware https://github.com/koenkk/z-stack-firmware.

Did you read the FAQ?

  • https://www.zigbee2mqtt.io/information/FAQ.html

Zigbee2MQTT fails to start?

  • https://www.zigbee2mqtt.io/information/FAQ.html#help-zigbee2mqtt-fails-to-start

Having issues when using a CC2531?

  • Make sure the CC2531 is connected through a USB extension cable
  • Try the source routing firmware: https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_Home_1.2/bin/source_routing
  • With larger networks (30/40+) devices, your CC2531 might not be powerful enough. This will cause weird issues, in this case it's advised to use a more powerful adapter: https://www.zigbee2mqtt.io/information/supported_adapters.html#texas-instruments-cc26x2r1

Unsupported device?

  • https://www.zigbee2mqtt.io/how_tos/how_to_support_new_devices.html

Device does not pair or interview fails?

  • https://www.zigbee2mqtt.io/information/FAQ.html#why-does-my-device-not-or-fail-to-pair

Bug report?

  • If applicable, provide steps how to reproduce the problem.
  • Provide the herdsman debug logging: https://www.zigbee2mqtt.io/information/debug.html#zigbee-herdsman-debug-logging

-->

<!--Start your bug report below this line-->

What happened

With the changes in https://github.com/Koenkk/zigbee-OTA/pull/47, I'm seeing an invalid image error when trying to update certain Philips Hue bulbs. The bulbs are Hue white ambiance E26/E27 and I'm trying to upgrade them from factory firmware (build date 20160810; version 5.50.1.19085). Running zigbee2mqtt automatically points at the latest master of zigbee-OTA, z2m successfully downloads and verifies the hash of this firmware (https://github.com/Koenkk/zigbee-OTA/blob/2ee5d02b6696ef04fb2b95f6175447705e4cbf46/index.json#L81-L88), but the update fails as being invalid.

Flicking back to the previous commit (by editing the URL in node_modules/zigbee-herdsman-converters/lib/ota/zigbeeOTA.js) allows the update to succeed with the previous latest firmware (build date 20191216; version 5.130.1.30000). Once on this firmware, requesting a subsequent OTA to the newest, current firmware is able to succeed.

What did you expect to happen

Perhaps specific device/firmware version combinations could have a specific upgrade path specified, or otherwise a way of selecting which firmware to upgrade to could be options to handle a situation like this.

How to reproduce it (minimal and precise)

Debug info

Zigbee2MQTT version: 1.21.1 Adapter hardware: zzh Adapter firmware version: 20210708

debug 2021-09-11 08:46:19: Got OTA request '{"fieldControl":0,"manufacturerCode":4107,"imageType":260,"fileVersion":1107315341}'
info  2021-09-11 08:46:19: MQTT publish: topic 'zigbee2mqtt/light_ceiling', payload '{"brightness":254,"color_mode":"color_temp","color_temp":249,"last_seen":"2021-09-10T22:46:19.703Z","linkquality":30,"
state":"ON","update":{"state":"available"},"update_available":true}'
debug 2021-09-11 08:46:19: getNewImage for '0x00deadbeefdeadbeef', meta {"fileVersion":1124096001,"fileSize":256696,"url":"http://fds.dc1.philips.com/firmware/ZGB_100B_0104/1124096001/Atmel_0104_ConnectedLamp-Target
_0012_88.1.sbl-ota","sha512":"39d64d99d718c82aa9874fb544497955b6cdbe7bff60bef19740c811a5af14eb02864f4a76ac01b7619882f317d4058f30b5b729fedb1789b564103bac7ac58c"}
debug 2021-09-11 08:46:21: OTA update checksum validation succeeded for '0x00deadbeefdeadbeef'
debug 2021-09-11 08:46:21: getNewImage for '0x00deadbeefdeadbeef', image header {"otaUpgradeFileIdentifier":{"type":"Buffer","data":[30,241,238,11]},"otaHeaderVersion":256,"otaHeaderLength":56,"otaHeaderFieldControl
":0,"manufacturerCode":4107,"imageType":260,"fileVersion":1124096001,"zigbeeStackVersion":2,"otaHeaderString":"\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000
\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000","totalImageSize":256696}
debug 2021-09-11 08:46:21: Got new image for '0x00deadbeefdeadbeef'
debug 2021-09-11 08:46:21: Starting upgrade
debug 2021-09-11 08:46:28: OTA update at 0%, remaining Infinity seconds
debug 2021-09-11 08:46:28: Update failed with reason: 'invalid image'
debug 2021-09-11 08:46:28: Update of 'light_ceiling' failed (Error: Update failed with reason: 'invalid image')

created time in 17 days