error Unsported attribute

Beim Start vom Adapter werden einige Fehler ausgegeben das einige Attribute nicht unterstützt werden.
LOG file im Debug Modus:
2023-01-29 17:20:27.915 - info: host.iobroker "system.adapter.roborock.0" enabled
2023-01-29 17:20:28.170 - info: host.iobroker instance system.adapter.roborock.0 started with pid 31871
2023-01-29 17:20:29.644 - debug: roborock.0 (31871) Redis Objects: Use Redis connection: <IP_ADDRESS>:9001
2023-01-29 17:20:29.697 - debug: roborock.0 (31871) Objects client ready ... initialize now
2023-01-29 17:20:29.700 - debug: roborock.0 (31871) Objects create System PubSub Client
2023-01-29 17:20:29.701 - debug: roborock.0 (31871) Objects create User PubSub Client
2023-01-29 17:20:29.778 - debug: roborock.0 (31871) Objects client initialize lua scripts
2023-01-29 17:20:29.785 - debug: roborock.0 (31871) Objects connected to redis: <IP_ADDRESS>:9001
2023-01-29 17:20:29.830 - debug: roborock.0 (31871) Redis States: Use Redis connection: <IP_ADDRESS>:9000
2023-01-29 17:20:30.028 - debug: roborock.0 (31871) States create System PubSub Client
2023-01-29 17:20:30.030 - debug: roborock.0 (31871) States create User PubSub Client
2023-01-29 17:20:30.373 - debug: roborock.0 (31871) States connected to redis: <IP_ADDRESS>:9000
2023-01-29 17:20:33.040 - info: roborock.0 (31871) starting. Version 0.0.6-alpha.0 (non-npm: copystring/ioBroker.roborock#280ee876636a28a98b7e46c9070f6f180b75e78e) in /opt/iobroker/node_modules/iobroker.roborock, node: v16.18.1, js-controller: 4.0.24
2023-01-29 17:20:33.616 - debug: roborock.0 (31871) RoomIDs debug: {"7803180":"Wohnzimmer","7803181":"Wohnzimmer1"}
2023-01-29 17:20:33.673 - info: roborock.0 (31871) MQTT initialized
2023-01-29 17:20:33.683 - debug: roborock.0 (31871) Products: object
2023-01-29 17:20:33.684 - debug: roborock.0 (31871) Product result: 42yfoQm5eOY3gARZw6xgU
2023-01-29 17:20:33.685 - debug: roborock.0 (31871) Product model: roborock.vacuum.a27
2023-01-29 17:20:33.686 - debug: roborock.0 (31871) Products: object
2023-01-29 17:20:33.686 - debug: roborock.0 (31871) Product result: 42yfoQm5eOY3gARZw6xgU
2023-01-29 17:20:33.687 - debug: roborock.0 (31871) Product model: roborock.vacuum.a27
2023-01-29 17:20:33.687 - debug: roborock.0 (31871) Robot key: roborock.vacuum.a27
2023-01-29 17:20:34.136 - debug: roborock.0 (31871) Latest data requested
2023-01-29 17:20:34.137 - debug: roborock.0 (31871) getParameter: get_status
2023-01-29 17:20:34.143 - debug: roborock.0 (31871) getParameter: get_water_box_custom_mode
2023-01-29 17:20:34.145 - debug: roborock.0 (31871) getParameter: get_consumable
2023-01-29 17:20:34.147 - debug: roborock.0 (31871) getParameter: get_network_info
2023-01-29 17:20:34.151 - debug: roborock.0 (31871) getParameter: get_carpet_mode
2023-01-29 17:20:34.152 - debug: roborock.0 (31871) getParameter: get_carpet_clean_mode
2023-01-29 17:20:34.153 - debug: roborock.0 (31871) getParameter: get_fw_features
2023-01-29 17:20:34.154 - debug: roborock.0 (31871) Firmware features request
2023-01-29 17:20:34.155 - debug: roborock.0 (31871) getParameter: get_multi_maps_list
2023-01-29 17:20:34.156 - debug: roborock.0 (31871) getParameter: get_room_mapping
2023-01-29 17:20:34.157 - debug: roborock.0 (31871) get_room_mapping
2023-01-29 17:20:34.492 - debug: roborock.0 (31871) dps debug: {"id":5,"result":{"clean_time":148203,"clean_area":2472042500,"clean_count":91,"dust_collection_count":62,"records":[1675004880,1674817136,1674480585,1674064193,1674064152,1674064088,1674064035,1674063969,1674063883,1673692065,1671436801,1671177602,1670832002,1670572801,1670240806,1670227201,1669968002,1669622402,1669363202,1669017602]}}
2023-01-29 17:20:34.519 - debug: roborock.0 (31871) dps debug: {"id":4,"result":{"ssid":"Tool_2G","ip":"xxx.xxx.xxx.xxx","mac":"xx:xx:xx:xx:xx:xx","bssid":"4c:ed:fb:a0:9d:79","rssi":-43}}
2023-01-29 17:20:34.522 - debug: roborock.0 (31871) dps debug: {"id":7,"result":[{"carpet_clean_mode":1}]}
2023-01-29 17:20:34.524 - debug: roborock.0 (31871) dps debug: {"id":6,"result":[{"enable":1,"current_integral":450,"current_high":500,"current_low":400,"stall_time":10}]}
2023-01-29 17:20:34.545 - debug: roborock.0 (31871) dps debug: {"id":1,"result":[{"msg_ver":2,"msg_seq":5049,"state":8,"battery":100,"clean_time":19,"clean_area":0,"error_code":0,"map_present":1,"in_cleaning":0,"in_returning":0,"in_fresh_state":1,"lab_status":3,"water_box_status":1,"back_type":-1,"wash_phase":0,"wash_ready":0,"fan_power":104,"dnd_enabled":0,"map_status":3,"is_locating":0,"lock_status":0,"water_box_mode":201,"water_box_carriage_status":1,"mop_forbidden_enable":1,"camera_status":421,"is_exploring":0,"home_sec_status":0,"home_sec_enable_password":1,"adbumper_status":[0,0,0],"water_shortage_status":0,"dock_type":3,"dust_collection_status":0,"auto_dust_collection":1,"avoid_count":0,"mop_mode":300,"debug_mode":0,"collision_avoid_status":1,"switch_map_mode":0,"dock_error_status":0,"charge_status":1,"unsave_map_reason":0,"unsave_map_flag":0}]}
2023-01-29 17:20:34.547 - debug: roborock.0 (31871) get_status: {"msg_ver":2,"msg_seq":5049,"state":8,"battery":100,"clean_time":19,"clean_area":0,"error_code":0,"map_present":1,"in_cleaning":0,"in_returning":0,"in_fresh_state":1,"lab_status":3,"water_box_status":1,"back_type":-1,"wash_phase":0,"wash_ready":0,"fan_power":104,"dnd_enabled":0,"map_status":3,"is_locating":0,"lock_status":0,"water_box_mode":201,"water_box_carriage_status":1,"mop_forbidden_enable":1,"camera_status":421,"is_exploring":0,"home_sec_status":0,"home_sec_enable_password":1,"adbumper_status":[0,0,0],"water_shortage_status":0,"dock_type":3,"dust_collection_status":0,"auto_dust_collection":1,"avoid_count":0,"mop_mode":300,"debug_mode":0,"collision_avoid_status":1,"switch_map_mode":0,"dock_error_status":0,"charge_status":1,"unsave_map_reason":0,"unsave_map_flag":0}
2023-01-29 17:20:34.549 - error: roborock.0 (31871) Unsported attribute: back_type of get_status. Please contact the dev to add the newly found attribute of your robot.
2023-01-29 17:20:34.549 - error: roborock.0 (31871) Unsported attribute: wash_phase of get_status. Please contact the dev to add the newly found attribute of your robot.
2023-01-29 17:20:34.549 - error: roborock.0 (31871) Unsported attribute: wash_ready of get_status. Please contact the dev to add the newly found attribute of your robot.
2023-01-29 17:20:34.550 - error: roborock.0 (31871) Unsported attribute: camera_status of get_status. Please contact the dev to add the newly found attribute of your robot.
2023-01-29 17:20:34.550 - error: roborock.0 (31871) Unsported attribute: is_exploring of get_status. Please contact the dev to add the newly found attribute of your robot.
2023-01-29 17:20:34.551 - error: roborock.0 (31871) Unsported attribute: home_sec_status of get_status. Please contact the dev to add the newly found attribute of your robot.
2023-01-29 17:20:34.551 - error: roborock.0 (31871) Unsported attribute: home_sec_enable_password of get_status. Please contact the dev to add the newly found attribute of your robot.
2023-01-29 17:20:34.552 - error: roborock.0 (31871) Unsported attribute: avoid_count of get_status. Please contact the dev to add the newly found attribute of your robot.
2023-01-29 17:20:34.552 - error: roborock.0 (31871) Unsported attribute: collision_avoid_status of get_status. Please contact the dev to add the newly found attribute of your robot.
2023-01-29 17:20:34.553 - error: roborock.0 (31871) Unsported attribute: switch_map_mode of get_status. Please contact the dev to add the newly found attribute of your robot.
2023-01-29 17:20:34.553 - error: roborock.0 (31871) Unsported attribute: charge_status of get_status. Please contact the dev to add the newly found attribute of your robot.
2023-01-29 17:20:34.565 - debug: roborock.0 (31871) dps debug: {"id":3,"result":[{"main_brush_work_time":80655,"side_brush_work_time":14808,"filter_work_time":144571,"filter_element_work_time":0,"sensor_dirty_time":14764,"strainer_work_times":0,"dust_collection_work_times":62,"cleaning_brush_work_times":0}]}
2023-01-29 17:20:34.570 - debug: roborock.0 (31871) dps debug: {"id":2,"result":{"water_box_mode":201}}
2023-01-29 17:20:34.574 - debug: roborock.0 (31871) dps debug: {"id":10,"result":[[16,"",13],[17,"",6],[18,"",14],[19,"",12],[20,"",8],[21,"",13]]}
2023-01-29 17:20:34.576 - debug: roborock.0 (31871) get_room_mapping: [[16,"",13],[17,"",6],[18,"",14],[19,"",12],[20,"",8],[21,"",13]]
2023-01-29 17:20:34.584 - debug: roborock.0 (31871) dps debug: {"id":8,"result":[111,112,113,114,115,116,117,118,119,120,121,122,123,124,125]}
2023-01-29 17:20:34.586 - debug: roborock.0 (31871) dps debug: {"id":9,"result":[{"max_multi_map":4,"max_bak_map":1,"multi_map_count":1,"map_info":[{"mapFlag":0,"add_time":1674821926,"length":2,"name":"EG","bak_maps":[{"mapFlag":4,"add_time":1673702497}]}]}]}
2023-01-29 17:20:34.602 - debug: roborock.0 (31871) dps debug: {"id":16,"result":[{"begin":1674064088,"end":1674064110,"duration":11,"area":0,"error":0,"complete":0,"start_type":2,"clean_type":3,"finish_reason":60,"dust_collection_status":0,"avoid_count":0,"wash_count":0,"map_flag":0}]}
2023-01-29 17:20:34.603 - debug: roborock.0 (31871) dps debug: {"id":11,"result":[{"begin":1675004880,"end":1675004914,"duration":19,"area":0,"error":0,"complete":0,"start_type":2,"clean_type":1,"finish_reason":60,"dust_collection_status":0,"avoid_count":0,"wash_count":0,"map_flag":0}]}
2023-01-29 17:20:34.607 - debug: roborock.0 (31871) dps debug: {"id":14,"result":[{"begin":1674064193,"end":1674064230,"duration":1,"area":0,"error":0,"complete":0,"start_type":2,"clean_type":3,"finish_reason":60,"dust_collection_status":0,"avoid_count":0,"wash_count":0,"map_flag":0}]}
2023-01-29 17:20:34.609 - debug: roborock.0 (31871) dps debug: {"id":18,"result":[{"begin":1674063969,"end":1674063985,"duration":11,"area":0,"error":0,"complete":0,"start_type":2,"clean_type":3,"finish_reason":60,"dust_collection_status":0,"avoid_count":0,"wash_count":0,"map_flag":0}]}
2023-01-29 17:20:34.611 - debug: roborock.0 (31871) dps debug: {"id":19,"result":[{"begin":1674063883,"end":1674063907,"duration":12,"area":0,"error":0,"complete":0,"start_type":2,"clean_type":3,"finish_reason":60,"dust_collection_status":0,"avoid_count":0,"wash_count":0,"map_flag":0}]}
2023-01-29 17:20:34.613 - debug: roborock.0 (31871) dps debug: {"id":12,"result":[{"begin":1674817136,"end":1674821615,"duration":2917,"area":50342500,"error":0,"complete":1,"start_type":2,"clean_type":1,"finish_reason":52,"dust_collection_status":1,"avoid_count":50,"wash_count":7,"map_flag":0}]}
2023-01-29 17:20:34.615 - debug: roborock.0 (31871) dps debug: {"id":22,"result":[{"begin":1671177602,"end":1671181985,"duration":2892,"area":49892500,"error":0,"complete":1,"start_type":2,"clean_type":3,"finish_reason":56,"dust_collection_status":1,"avoid_count":91,"wash_count":7,"map_flag":0}]}
2023-01-29 17:20:34.618 - debug: roborock.0 (31871) dps debug: {"id":13,"result":[{"begin":1674480585,"end":1674485028,"duration":2938,"area":49950000,"error":0,"complete":1,"start_type":2,"clean_type":1,"finish_reason":52,"dust_collection_status":1,"avoid_count":80,"wash_count":7,"map_flag":0}]}
2023-01-29 17:20:34.620 - debug: roborock.0 (31871) dps debug: {"id":17,"result":[{"begin":1674064035,"end":1674064041,"duration":6,"area":0,"error":0,"complete":0,"start_type":2,"clean_type":3,"finish_reason":37,"dust_collection_status":0,"avoid_count":0,"wash_count":0,"map_flag":0}]}
2023-01-29 17:20:34.622 - debug: roborock.0 (31871) dps debug: {"id":23,"result":[{"begin":1670832002,"end":1670836467,"duration":2982,"area":50212500,"error":0,"complete":1,"start_type":2,"clean_type":3,"finish_reason":56,"dust_collection_status":1,"avoid_count":73,"wash_count":7,"map_flag":0}]}
2023-01-29 17:20:34.623 - debug: roborock.0 (31871) dps debug: {"id":27,"result":[{"begin":1669968002,"end":1669972431,"duration":2933,"area":50735000,"error":0,"complete":1,"start_type":2,"clean_type":3,"finish_reason":56,"dust_collection_status":1,"avoid_count":60,"wash_count":7,"map_flag":0}]}
2023-01-29 17:20:34.625 - debug: roborock.0 (31871) dps debug: {"id":25,"result":[{"begin":1670240806,"end":1670241322,"duration":401,"area":5225000,"error":0,"complete":1,"start_type":2,"clean_type":3,"finish_reason":56,"dust_collection_status":1,"avoid_count":21,"wash_count":2,"map_flag":0}]}
2023-01-29 17:20:34.627 - debug: roborock.0 (31871) dps debug: {"id":26,"result":[{"begin":1670227201,"end":1670231621,"duration":2919,"area":50545000,"error":0,"complete":1,"start_type":2,"clean_type":3,"finish_reason":56,"dust_collection_status":1,"avoid_count":69,"wash_count":7,"map_flag":0}]}
2023-01-29 17:20:34.666 - debug: roborock.0 (31871) dps debug: {"id":29,"result":[{"begin":1669363202,"end":1669367380,"duration":2976,"area":50482500,"error":0,"complete":1,"start_type":2,"clean_type":3,"finish_reason":56,"dust_collection_status":1,"avoid_count":70,"wash_count":6,"map_flag":0}]}
2023-01-29 17:20:34.668 - debug: roborock.0 (31871) dps debug: {"id":21,"result":[{"begin":1671436801,"end":1671441403,"duration":3073,"area":50452500,"error":0,"complete":1,"start_type":2,"clean_type":3,"finish_reason":56,"dust_collection_status":1,"avoid_count":50,"wash_count":7,"map_flag":0}]}
2023-01-29 17:20:34.669 - debug: roborock.0 (31871) dps debug: {"id":24,"result":[{"begin":1670572801,"end":1670577246,"duration":2885,"area":50335000,"error":0,"complete":1,"start_type":2,"clean_type":3,"finish_reason":56,"dust_collection_status":1,"avoid_count":78,"wash_count":7,"map_flag":0}]}
2023-01-29 17:20:34.689 - warn: roborock.0 (31871) State "roborock.0.Devices.7BzNvpqlCv03aXgw55hjDs.consumables.strainer_work_times" has no existing object, this might lead to an error in future versions
2023-01-29 17:20:34.689 - warn: roborock.0 (31871) State "roborock.0.Devices.7BzNvpqlCv03aXgw55hjDs.consumables.cleaning_brush_work_times" has no existing object, this might lead to an error in future versions
2023-01-29 17:20:34.691 - debug: roborock.0 (31871) dps debug: {"id":15,"result":[{"begin":1674064152,"end":1674064174,"duration":12,"area":0,"error":0,"complete":0,"start_type":2,"clean_type":3,"finish_reason":60,"dust_collection_status":0,"avoid_count":0,"wash_count":0,"map_flag":0}]}
2023-01-29 17:20:34.693 - debug: roborock.0 (31871) dps debug: {"id":28,"result":[{"begin":1669622402,"end":1669626816,"duration":2917,"area":50380000,"error":0,"complete":1,"start_type":2,"clean_type":3,"finish_reason":56,"dust_collection_status":1,"avoid_count":52,"wash_count":6,"map_flag":0}]}
2023-01-29 17:20:34.694 - debug: roborock.0 (31871) dps debug: {"id":30,"result":[{"begin":1669017602,"end":1669021982,"duration":2928,"area":49900000,"error":0,"complete":1,"start_type":2,"clean_type":3,"finish_reason":56,"dust_collection_status":1,"avoid_count":68,"wash_count":7,"map_flag":0}]}
2023-01-29 17:20:34.696 - debug: roborock.0 (31871) dps debug: {"id":20,"result":[{"begin":1673692065,"end":1673696483,"duration":2872,"area":49602500,"error":0,"complete":1,"start_type":2,"clean_type":1,"finish_reason":52,"dust_collection_status":1,"avoid_count":96,"wash_count":7,"map_flag":0}]}
`
Versions:

Adapter version: 0.0.6-alpha.0
JS-Controller version: 4.0.24
Node version: 16.18.1
Operating system: Docker / Linux

Please try this branch for me and post a new log via pastebin or by attaching it as a file.
https://github.com/copystring/ioBroker.roborock/tree/update_robot_attributes

Habe ich jetzt installiert und es sind keine Fehler mehr vorhanden.
Hier das LOG im Debug Modus:
LOG_30.02.2023.txt

Wenn dein Problem gelöst ist dann bitte schließen. Danke.


errorhandling in try load template

After improving the template inclusion by the patch in #277
When handling nested includes where A includes B I get displayed the error "A not found" when including B fails. The log will show an appropriate error generated by the java code below.
How does the code have to look like that the error "B not found" is shown? tryLoadTemplate seems to have no option to throw a ParseException itself or other means to signal such a problem. Please advise.
 @Override
  public TemplateClass tryLoadTemplate(String tmplName, RythmEngine engine,
      TemplateClass callerClass, ICodeType codeType) {
    if (engine.templateRegistered(tmplName))
      return null;
    if (!tmplName.startsWith("wiki."))
      return null;
    String rythmSuffix = engine.conf().resourceNameSuffix();
    String key = tmplName;
    LOGGER.log(Level.INFO, "Loading wiki template '" + tmplName
        + "' for ryhtmSuffix "+rythmSuffix);
    TemplateClass tc = engine.classes().getByTemplate(key);
    if (tc == null) {
      try {
        WikiTemplateResource wikiTemplate=getResource(key);
        if (wikiTemplate==null) {
          throw new IllegalArgumentException("Template for "+key+" not found");
        }
        tc = new TemplateClass(wikiTemplate, engine);
        ITemplate template = tc.asTemplate(engine);
        if (null != template) {
           engine.registerTemplate(key, template);
        }
      } catch (Throwable th) {
        handle("tryLoadTemplate",th);
      }
    }
    return tc;
  }

#279 is a pull request with a proposed change.

There is a followup problem Error: java.util.UnknownFormatConversionException that can be fixed by adding another constructor to ParseException that will not use the format ... call


Fix subscription_level_deployment test.

This checklist is used to make sure that common guidelines for a pull request are followed.

[ ] The PR has modified HISTORY.rst describing any customer-facing, functional changes. Note that this does not include changes only to help content. (see Modifying change log).

[ ] I adhere to the Command Guidelines.

Codecov Report

Merging #6669 into dev will not change coverage.
The diff coverage is n/a.

@@         Coverage Diff         @@
##           dev   #6669   +/-   ##
===================================
  Coverage    0%      0%
===================================
  Files       11      11
  Lines      145     145
  Branches    11      11
===================================
  Misses     145     145

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 33256a3...995eb31. Read the comment docs.


FHIR Search Feature: _include:iterate

FHIR Search has a _include which can be iterative, if (and only if) the modifier :iterate is included
https://www.hl7.org/fhir/search.html#include
The inclusion process can be iterative, if (and only if) the modifier :iterate is included. For
example, this search returns all Medication Request resources and their prescribing
Practitioner Resources for the matching Medication Dispense resources:

GET [base]/MedicationDispense?_include=MedicationDispense:prescription
    &_include:iterate=MedicationRequest:performer&criteria...

Example from PDXNET: {{url}}/Practitioner?identifier=1230782571&_revinclude=PractitionerRole:practitioner&_include:iterate=PractitionerRole:organization

I recommend we only consider going up to one level for the iterate.  Otherwise it just gets too hard and performance becomes a bigger concern.

High-level design doc attached.
issue1158_design.docx

Updated design doc attached.[
issue1158_design_v2.docx
](url)

Looks good... sample created linked patients and then iterated over it.
{
    "resourceType": "Bundle",
    "id": "a34d9d6b-3fce-4311-8c45-3ac612540814",
    "type": "searchset",
    "total": 1,
    "link": [
        {
            "relation": "self",
            "url": "https://localhost:9443/fhir-server/api/v4/Patient?_count=10&_id=1784aa352aa-2bdc10a1-4b4d-405e-a8a1-bd1c19afdca5&_include:iterate=Patient:link:Patient&_include:iterate=Patient:link:RelatedPerson&_page=1"
        }
    ],
    "entry": [
        {
            "fullUrl": "https://localhost:9443/fhir-server/api/v4/Patient/1784aa352aa-2bdc10a1-4b4d-405e-a8a1-bd1c19afdca5",
            "resource": {
                "resourceType": "Patient",
                "id": "1784aa352aa-2bdc10a1-4b4d-405e-a8a1-bd1c19afdca5",
                "meta": {
                    "versionId": "1",
                    "lastUpdated": "2021-03-29T18:02:29.285271Z"
                },
                "active": true,
                "name": [
                    {
                        "family": "Ortiz",
                        "given": [
                            "David"
                        ]
                    }
                ],
                "gender": "male",
                "link": [
                    {
                        "other": {
                            "reference": "Patient/1784aa352aa-2bdc10a1-4b4d-405e-a8a1-bd1c19afdca4"
                        },
                        "type": "seealso"
                    }
                ]
            },
            "search": {
                "mode": "match",
                "score": 1
            }
        },
        {
            "fullUrl": "https://localhost:9443/fhir-server/api/v4/Patient/1784aa352aa-2bdc10a1-4b4d-405e-a8a1-bd1c19afdca4",
            "resource": {
                "resourceType": "Patient",
                "id": "1784aa352aa-2bdc10a1-4b4d-405e-a8a1-bd1c19afdca4",
                "meta": {
                    "versionId": "3",
                    "lastUpdated": "2021-03-29T18:00:43.412148Z"
                },
                "active": true,
                "name": [
                    {
                        "family": "Ortiz",
                        "given": [
                            "David"
                        ]
                    }
                ],
                "gender": "male",
                "link": [
                    {
                        "other": {
                            "reference": "Patient/1784aa352aa-2bdc10a1-4b4d-405e-a8a1-bd1c19afdca4"
                        },
                        "type": "seealso"
                    }
                ]
            },
            "search": {
                "mode": "include",
                "score": 1
            }
        }
    ]
}


[SwiftUI] No symbol named 'gear.circle' found

Hi Erik,
i discover this issue on Big Sur  during my testing Hello 0.2.2 .

2021-07-22 18:46:22.523077+0200 hello[40018:764438] [SwiftUI] No symbol named 'gear.circle' found in system symbol set
2021-07-22 18:46:22.554990+0200 hello[40018:764438] [SwiftUI] No symbol named 'gear.circle' found in system symbol set
2021-07-22 18:46:25.067170+0200 hello[40018:764438] [SwiftUI] No symbol named 'gear.circle' found in system symbol set
2021-07-22 18:46:25.166747+0200 hello[40018:764438] [SwiftUI] No symbol named 'circle.dashed.inset.filled' found in system symbol set

Hi Trekkim,
While testing on Big Sur you will want to make sure that the SF Symbol is compatible with the OS you're testing on.  In this case, the image listed in Erik's example is from the SF Beta and is compatible with Monterey.  Alternatively, in my testing on Big Sur I changed this to "welcomeScreenItem1SymbolName": "gear"

Hi  cdog2020,
can you please share here where exactly cause i changed, but still  No Symbol error.

thx

Hey Trekkim,
It looks to me like you're editing the project itself.  I was speaking to changing that in the JSON for the already built version of hello.  I have not edited anything in the swift project in testing.

Ok, yeap i wanna  understand little bit  how it is written ;-)

I sorted 2021-07-22 18:46:25.166747+0200 hello[40018:764438] [SwiftUI] No symbol named 'circle.dashed.inset.filled' found in
just changed circle.dashed.inset.filled to circle.dashed.inset.fill :-)

hello should do something like
Image(systemName: symbolName) ?? Image(systemName: questionmark.square.fill) to handle this.

Have a solution for this in #8, but it isn't as nice as your one liner (I couldn't get it to work as swift is a lot of lolwut at times :D ).


Try to read a second smartcard fails.

Situation:
Server 2012R2 as terminal server.
Users using FreeRDP to log on and running an application.
Using  wfreerdp /f /v:cloud.compufit.be /u:domainname\username /p:******** /a:smartcard,"OMNIKEY 3x21"
Problem:
Reading for the first time a smartcard is ok. But after removing the card and input the same or another one it is not possible to read the card. The software to read the card is shown up so you can verify to read the card. The window disappear but nothing happens.
Same problem on OSX.
Only disconnecting and reconnecting helps.
No errors displayed or found in logs.
Using another remote desktop program like RDP plus, Remote Desktop Connection manager 2.7 or MTSC does not give problems with the smartcard or smartcard reader.
It looks like this is a bug.

#4312 fixed a bunch of smartcard related issues bringing it to a usable state again.
Reopen, if your specific issue was not fixed.


[BUG FIX] JSON Serialize Decimal

Description:
Related issue (if applicable): fixes #13021
Checklist:

[x] The code change is tested and works locally.
[x] Local tests pass with tox. Your PR cannot be merged unless tests pass

I don't think the solution is to add it to our JSON encoder. Instead, SQL sensor should not store decimals in the state machine to begin with. It's not up to us to decide that all decimal values can be represented as a float.

I tried to repro it with SQLite but it never returns the decimal type. Must be a MySQL thing or something.

It was the update from 0.64 to 0.65 that triggered this bug
Decimal is not sqlalchemy exclusive, other libs in the future can trigger the same issue, will we replicate #13059 throughout the code in the future ?

We will. If the precision is important, the decimal should be converted to a string. It's not up to us  to decide that precision is not important and convert it to a float.

I understand you desire to ring-fence the issue to the source.
But the issue at hand is related to JSON serialisation, not with internal issues (might be forgetting something here)
A decimal in the state machine should be no different then of a set (which is still considered)
A 2nd order sensor that could use the precision of decimal will be stripped of the possibility.

All data in the state machine should be JSON serializable. (we also test this)
The driver behind this is that we want to be able to have a multi-Home Assistant setup and thus need to be able to share states via JSON without having to worry about all the different types that can be int the state machine

And so the issue here is not JSON serialization, it's that the SQL sensor violated this unwritten rule.

But this PR actually enables the serialization of Decimal...
Libraries such as Simplejson actually opt for Decimal instead of float.

The problem is that by enabling serialization of Decimal, you should also always deserialize to Decimal or else you still lose precision. Also, sometimes you don't care about precision (or it was never there) and you don't want people consuming your API to have to convert it to a float themselves.

I've merged the other PR since it's the right solution.


[FEATURE] Add order endpoint to API client and implement view

Description

success page
Acceptance criteria

[ ] add endpoint from #262
[ ] implement view using provided endpoint

blocked until 6.2 is released

There is a possibility to get the customer's order by providing only the order ID, but the customer must be logged in - for some reason, even if the customer placed order as a guest - API treats him as a logged-in so there is no reason to be worried about :+1:
related PR -> https://github.com/DivanteLtd/shopware-pwa/pull/752


Don't create the embedded ansible default project

We don't currently provide any playbooks so we don't need this.
We do provide roles so we still need to gather up the content
provided by the plugins when the embedded_ansible role is enabled
on an appliance. So we still call
Ansible::Content.consolidate_plugin_playbooks here.
Making the roles accessible to other playbook runs is done by altering
the roles search path here:
https://github.com/ManageIQ/manageiq-appliance/blob/9f0e0ed0381785387207343867173888e0b60788/LINK/root/.ansible.cfg#L3
Creating this project will cause an issue when we need to run the
embedded ansible role on multiple appliances. Each appliance would
have created the source SCM locally and the git shas would not match
between the different appliances which would cause issues with the
GitRepository model we use for managing ConfigurationScriptSources.
In the future if we do choose to provide playbooks out of the box
from plugins we can re-evaluate how to deal with this scenario at
that time.

Not sure what the thoughts are here on a data migration. I think we might run into a related issue for upgrades because the previous location of this project was not the same one we have here.
Previously we used /var/lib/awx_consolidated_source and for the last few weeks we've been using /var/www/miq/vmdb/content/ansible_consolidated/ so I could conceive of a data migration to remove any repo with one of those file urls ...

Okay, after just seeing this comment:
https://github.com/ManageIQ/manageiq/pull/19056#issuecomment-514812686
I am going to remove my approval as I am less certain of the overall effects of making this change when doing an upgrade.

To be clear. We might need the migration either way to make sure we don't have a repo hanging around with the old path. So that might be a good place to get rid of repos with either of these paths.

I agree with your analysis here.  If we don't need the default project it's better to drop it, but I definitely think we need a data migration to remove it from an existing embedded ansible provider.
cc @agrare @gmcculloug @gtanzillo @jrafanie This removes the ability to provide playbooks from a plugin repo, but it wasn't being used and we can add it back in later in a better way.  At present only the roles for manageiq's API access were in the content repo, and we haven't change the part where those roles are available.  I just want to check, but were provider playbooks expected to be accessible from EmbeddedAnsible (i.e. via services or automate)?

I just want to check, but were provider playbooks expected to be accessible from EmbeddedAnsible (i.e. via services or automate)?

AFAIK The playbooks in the provider repos e.g. manageiq-providers-nuage/content/ansible_runner/create-subnet.yml are meant to be self-contained and only intended to be called by ansible-runner from a provider operation, not from embedded_ansible.
If you wanted to create a nuage subnet from a service or automate it is expected that you would queue a ...::CloudSubnet.create_cloud_subnet call which would end up calling the playbook, not call the playbook directly.

Yeah, @agrare there are two different ways for plugins to provide ansible content. One is as you describe, the other got shoved into a "project" for the AWX-based embedded ansible.

ansible_content vs ansible_runner_content here:
https://github.com/ManageIQ/manageiq/blob/7146738a0ae43b586b883480d42d5ff2c39dd96c/lib/vmdb/plugins.rb#L37-L55

@carbonin correct, that was my long winded way of saying we dont' need to worry about the provider playbooks in this context.

Ivanchuk backport details:
$ git log -1
commit 85a9399af44b40826ffeca44190044f6763dbc3d
Author: Jason Frey<EMAIL_ADDRESS>Date:   Thu Jul 25 14:13:45 2019 -0400

    Merge pull request #19056 from carbonin/dont_create_a_default_project

    Don't create the embedded ansible default project

    (cherry picked from commit 564a6beb0e2a71f3ccc83f0c5306677185af948f)


current muscle (5) is not compatible

Dear IImog,
Thank you for the tool - Love it!! Just a heads up the current version of bcgTree does not play well with muscle (5) - current version . The error is:
..../bin/muscle -in gene_tree_120_conserved/TIGR00061.fa -out gene_tree_120_conserved/TIGR00061.aln
Invalid command line
Unknown option in
[09-07 11:29:47] [bcgTree]
[09-07 11:29:47] [bcgTree] ERROR: muscle on TIGR00061 failed
Solution: Downgrade to muscle 3.8
Pete

Hi Pete,
thanks a lot for raising this issue. I'll try to find a way to make bcgTree compatible with old and new versions of muscle. But for now I leave this issue open as information to other users.
Best,
Markus

Making bcgTree work with muscle 5 might be as easy as changing in to align in this line: https://github.com/molbiodiv/bcgTree/blob/dceaf223a92679e399aab367ca3ef29f618d94b7/lib/bcgTree.pm#L224
This would break compatibility with older muscle versions, though. I also need to do some testing that there are no other relevant changes between muscle versions, e.g. in the output format.

It would break backwards compatibility. Can you extract the version for the -v and apply the command accordingly?

Thanks for raising this, and yes it should be addressed. Thanks @iimog for taking care.
Once this is done, please also update the README, I have a while back made there a comment that only 3.8 is supported for now and posted a link to that binary:
dceaf223a92679e399aab367ca3ef29f618d94b7


CLI option to pre-compute cached dataframes

It would be useful to pre-compute the cached dataframes. Something like
python -m tsqc precompute <file>

should do the trick.
See #113, though

Fixed by #167


manifest: Update to latest upstream version

This update requires updating the siwx917 Bluetooth HCI devicetree binding as well, since the format for bt-hci-bus and bt-hci-quirks properties has changed.

The HCI binding update requirement comes from https://github.com/zephyrproject-rtos/zephyr/pull/79878

Btw, this was the first time we benefitted from the daily upstream build, since caught this issue last night: https://github.com/SiliconLabsSoftware/zephyr-silabs/actions/runs/11397949495/job/31714219990


Move logical expression type-coercion code from physical-expr crate to expr crate

Which issue does this PR close?

Closes https://github.com/apache/arrow-datafusion/issues/2251.
Rationale for this change

We have logic to determine the return type of various logical expressions and this logic is called from expr_schema.rs in the logical_plan module, but the code is located in the physical-expr crate and it does not need to be there.
We could move this logic into the datafusion-expr crate instead and remove many logical plan dependencies on the datafusion-physical-expr crate, as a step towards to moving the logical plan itself to datafusion-expr, which would allow us to have logical expressions that reference logical plans (needed for subquery support).
What changes are included in this PR?

This PR moves logical type coercion code from datafusion-physical-expr to datafusion-expr. There are no functional changes.
Note that physical type coercion logic remains in the physical-expr crate.

[x] Move aggregate type code (https://github.com/apache/arrow-datafusion/pull/2257/commits/0b7327d3a7a652360eb2089d807324c051901a8f)
[x] Move window function type code (https://github.com/apache/arrow-datafusion/pull/2257/commits/7bc25aef341931769fe15035b4d47f4099a4899f)
[x] Move scalar function type code (https://github.com/apache/arrow-datafusion/pull/2257/commits/6f1eadb1821f7572142175dc3aac9f2405ccb440)

Are there any user-facing changes?

Yes - code is moved between crates, so users will need to update their imports.

@alamb @Jimexist Apologies for the monster PR. I am happy to try and break this down into smaller changes if that will help with reviews. There are no functional changes, just moving code around to fix one of the dependency issues that is blocking me from making progress with subquery support.
I'm not sure who else I should be @ mentioning here so feel free to tag others that you think should review this.

The background of my thoughts back then was: there are two types of "coercion rules":

coercion rules that exist as a consequence of the supported ops from the physical engine (e.g. i32 + i64 -> cast(i32 AS i64) + i64 when the engine does not support i32 + i64).

coercion rules related to the semantic meaning of what the user wants. For example, a user usually wants sum(Vec<u8>) to be u64, not u8, to avoid numeric overflows.

imo the former is part of the step logical -> physical, the latter is part of the (run-time) type checking done when performing logical planning for schema resolution (i.e. what schema will the logical plan have)